NAS A/TM-20 14-2 18520 



FUN3D Manual: 12.5 


Robert T. Biedron, Joseph M. Derlaga, Peter A. Gnoffo, Dana P. Hammond, 

William T. Jones, Bil Kleb, Elizabeth M. Lee- Rausch, Eric J. Nielsen, Michael A. Park, 
Christopher L. Rumsey, James L. Thomas, and William A. Wood 
Langley Research Center 
Hampton, Virginia 23681 


September 2014 



NASA STI Program ... in Profile 


Since its founding, NASA has been dedicated 
to the advancement of aeronautics and space 
science. The NASA scientific and technical 
information (STI) program plays a key part 
in helping NASA maintain this important 
role. 

The NASA STI Program operates under the 
auspices of the Agency Chief Information 
Officer. It collects, organizes, provides for 
archiving, and disseminates NASA’s STI. 

The NASA STI Program provides access to 
the NASA Aeronautics and Space Database 
and its public interface, the NASA Technical 
Report Server, thus providing one of the 
largest collection of aeronautical and space 
science STI in the world. Results are 
published in both non-NASA channels and 
by NASA in the NASA STI Report Series, 
which includes the following report types: 

• TECHNICAL PUBLICATION. Reports of 
completed research or a major significant 
phase of research that present the results 
of NASA programs and include extensive 
data or theoretical analysis. Includes 
compilations of significant scientific and 
technical data and information deemed to 
be of continuing reference value. NASA 
counterpart of peer-reviewed formal 
professional papers, but having less 
stringent limitations on manuscript length 
and extent of graphic presentations. 

• TECHNICAL MEMORANDUM. 

Scientific and technical findings that are 
preliminary or of specialized interest, e.g., 
quick release reports, working papers, and 
bibliographies that contain minimal 
annotation. Does not contain extensive 
analysis. 

• CONTRACTOR REPORT. Scientific and 
technical findings by NASA-sponsored 
contractors and grantees. 


• CONFERENCE PUBLICATION. 
Collected papers from scientific and 
technical conferences, symposia, seminars, 
or other meetings sponsored or 
co-sponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, 
technical, or historical information from 
NASA programs, projects, and missions, 
often concerned with subjects having 
substantial public interest. 

• TECHNICAL TRANSLATION. English- 
language translations of foreign scientific 
and technical material pertinent to 
NASA’s mission. 

Specialized services also include creating 
custom thesauri, building customized 
databases, and organizing and publishing 
research results. 

For more information about the NASA STI 
Program, see the following: 

• Access the NASA STI program home page 

at http://www.sti.nasa.gov 

• E-mail your question via the Internet to 
help@sti.nasa.gov 

• Fax your question to the NASA STI 
Help Desk at 443-757-5803 

• Phone the NASA STI Help Desk at 
443-757-5802 

• Write to: 

NASA STI Help Desk 
NASA Center for AeroSpace 
Information 
7115 Standard Drive 
Hanover, MD 21076-1320 



NAS A/TM-20 14-2 18520 



FUN3D Manual: 12.5 


Robert T. Biedron, Joseph M. Derlaga, Peter A. Gnoffo, Dana P. Hammond, 

William T. Jones, Bil Kleb, Elizabeth M. Lee- Rausch, Eric J. Nielsen, Michael A. Park, 
Christopher L. Rumsey, James L. Thomas, and William A. Wood 
Langley Research Center 
Hampton, Virginia 23681 


National Aeronautics and 
Space Administration 

Langley Research Center 
Hampton, Virginia 23681 


September 2014 



The use of trademarks or names of manufacturers in this report is for accurate reporting and does not 
constitute an offical endorsement, either expressed or implied, of such products or manufacturers by the 
National Aeronautics and Space Administration. 


Available from: 


NASA Center for AeroSpace Information 
7115 Standard Drive 
Hanover, MD 21076-1320 
443-757-5802 




Abstract 


This manual describes the installation and execution of FUN3D version 12.5, 
including optional dependent packages. FUN3D is a suite of computational 
fluid dynamics simulation and design tools that uses mixed-element unstruc- 
tured grids in a large number of formats, including structured multiblock 
and overset grid systems. A discretely-exact adjoint solver enables efficient 
gradient-based design and grid adaptation to reduce estimated discretization 
error. FUN3D is available with and without a reacting, real-gas capability. 
This generic gas option is available only for those persons that qualify for its 
beta release status. 
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About this Document 


This manual is intended to guide an application engineer through configura- 
tion, compiling, installing, and executing the Fun3D simulation package. The 
focus is on the most commonly exercised capabilities. Therefore, some of the 
immature or rarely exercised capabilities are intentionally omitted in the in- 
terest of clarity. An accompanying document that provides example cases is 
under development. 

Release of the generic gas capability is restricted because of International 
Traffic in Arms Regulations (ITAR), so Fun3D usually distributed with the 
generic gas capability disabled. See section 1.4 for details. This manual de- 
scribes Fun3D with and without the generic gas capability, denoted eqn_type= 
'generic' . Features that are specific to an eqn.type are explicitly indicated. 

This document is updated and released with each subsequent version of 
Fun3D. In fact, a significant portion is automatically extracted from the 
Fun3D source code. If you have difficulties, find any errors, or have any 
suggestions for improvement please contact the authors at 

Fun3D-Support@lists . nasa . gov 

We would like to hear from you. 
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Quick Start 

This section takes you from source code tarball to a rudimentary flow so- 
lution using single processor execution on a typical Unix-style environment 
(e.g. Linux, Mac® OS) with a Fortran compiler and the GNU Make utility. 
Fun3D is most commonly executed in parallel, but the intent here is to pro- 
vide the most basic installation, setup, and execution of the Fun3D flow solver 
without the complexity of any third-party libraries or packages. 

See section 1.4 for instructions on obtaining the Fun3D source code tarball. 
Once you have it, unpack the source code tarball, configure it for your system 
(section A), compile it, and add the executables directory to your search path. 
For C Shell, e.g., 

tar zxf fun3d-12 . 5-* . tar .gz 
cd fun3d-12.5-* 
mkdir _seq 
cd _seq 

../configure — pref ix=$-[PWD} 
make install 

setenv PATH ${PWD}/bin : ${PATH} 
cd . . 

For Bourne Shell, the setenv command is export PATH=${PWD>/bin : ${PATH}. 
The change to the PATH environment variable can be made permanently by 
adding the setenv or export command to your shell start up hie. Next, move 
to the doc/quick_start directory, 

cd doc/quick_start 

where you will find a very coarse 3D wing grid (inv_wing.fgrid) intended for 
inviscid how simulation (section 4). Also in this directory are the associated 
boundary conditions hie inv_wing.mapbc (section 3) and a Fun 3D input hie 
fun3d.nml in Fortran namelist format (section B.4). 

Execute the how solver (section 5.1) by running the command 

nodet 

This should produce screen output similar to 

1 FUN3D 12.5-71613 Flow started 09/16/2014 at 13:22:50 with 1 processes 

2 Contents of fun3d . nml file below 

3 &project 

4 project_rootname = 'inv_wing' 

5 / 

6 &raw_grid 

7 grid_format = 'fast' 

8 data_format = 'ascii' 

9 / 

10 &governing_equations 

11 viscous_terms = 'inviscid' 


ll 


12 / 

13 &ref erence_physical_properties 

14 mach_number = 0.7 

15 angle_of _attack = 2.0 

16 / 

17 &code_run_control 

18 restart_read = 'off' 

19 steps = 150 

20 stopping_tolerance = 1.0e-12 

21 / 

22 &global 

23 boundary_animation_freq = -1 

24 / 

25 Contents of fun3d . nml file above 

26 rotor. input not found 

27 

28 moving_body . input not found 

29 moving_body . input not found 

30 ... opening inv_wing . f grid 

31 ... nnodesg: 6309 ntet: 35880 ntface: 1392 

32 

33 cell statistics: type, min volume, max volume, max face angle 

34 cell statistics: tet, 0 . 38305628E-05 , 0 . 14174467E+02 , 143.526944837 

35 cell statistics: all, 0 . 38305628E-05 , 0 . 14174467E+02 , 143.526944837 

36 


37 

. . . Constructing partition node sets for 

level-0 . . . 

35880 T 

38 

. . . Edge Partitioning .... 



39 

. . . Boundary partitioning. . . . 



40 

. . . Reordering for cache efficiency. . . . 



41 

. . . Write global grid information to inv. 

_wing . grid_inf o 


42 

. . . Time after preprocess TIME/Mem(MB) : 

0.72 98.72 

98.72 


197 

76 

0 . 459743875675293E-12 0 . 20881E-10 

0 . 26803E+01 

0 . 00000E+00 -0.62327E+00 

198 


Lift 0 . 809996568758631E-01 

Drag 

0 . 107734796873048E-01 

199 

77 

0.347515632356081E-12 0.16460E-10 

0.26803E+01 

0 . 00000E+00 -0.62327E+00 

200 


Lift 0 . 809996568770187E-01 

Drag 

0 . 1 07734796873 170E-01 

201 

78 

0 . 264078581490539E-12 0 . 12961E-10 

0 . 26803E+01 

0 . 00000E+00 -0.62327E+00 

202 


Lift 0 . 809996568779106E-01 

Drag 

0 . 107734796873263E-01 

203 

79 

0 . 20 193955328 1957E- 12 0 . 10194E-10 

0 . 26803E+01 

0 . 00000E+00 -0.62327E+00 

204 


Lift 0 . 809996568785974E-01 

Drag 

0 . 107734796873335E-01 

205 






206 

Writing boundary output: inv_wing_tec_boundary . 

dat 


207 

Time 

step: 79, ntt: 79, Prior iterations 

: 0 



208 






209 

Writing inv_wing. f low (version 11.8) lmpi. 

_io 2 



210 

inserting current history iterations 79 




211 

Time 

for write: .0 s 




212 






213 

Done . 






If Fun 3D completed successfully, a Mach 0.7 inviscid flow over a very 
coarse representation of an ONERA M6 semi-span wing [1] at two degrees 
angle of attack is available. If not, please refer to Troubleshooting on page 299. 

With visualization software capable of reading Tecplot™ hies, you can visu- 
alize various surface quantities with inv_wing_tec_boundary.dat as shown by 
the pressure contours in Fig. 1. Iterative convergence history can be plotted 
from inv_wing_hist.dat as shown in Fig. 2. Histories of all five conservation 
equation residual norms are denoted R_1 -R_5, and the lift coefficient conver- 
gence history is denoted C_L. 
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Figure 1: Mach 0.7 flow about a coarse ONERA M6 semi-span wing at 2 
degrees angle of attack. 
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Figure 2: Iterative convergence history for coarse ONERA M6 wing. 
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1 Introduction 


Fun 3D began as a research code in the late 1980s. [2] The code was created 
to develop new algorithms for unstructured-grid fluid dynamic simulations 
of incompressible and compressible transonic flows. The project has since 
grown into a suite of codes that cover not only flow analysis, but adjoint-based 
error estimation, mesh adaptation, and design optimization of fluid dynamic 
problems extending into the hypersonic regime. [3] 

Fun3D is currently used as a production flow analysis and design tool to 
support NASA programs. Continued research efforts have also benefited by the 
improvements to stability, ease of use, portability, and performance that this 
shift to simultaneous support of development and production environments has 
required. These benefits also include the rapid evaluation of new techniques 
on realistic simulations and a rapid maturation of experimental techniques to 
production-level capabilities. 


1.1 Primary Capabilities and Features 

The primary capabilities of Fun 3D are: 

• Parallel domain decomposition with Message Passing Interface (MPI) 
communication for distributed computing 

• Two-dimensional (2D) and Three-dimensional (3D) node-based, finite- 
volume discretization 

• Thermodynamic models: perfect gas (compressible and incompressible) 
and thermochemical equilibrium, and non-equilibrium 1 

• Time-accurate options from first- to fourth-order with temporal error 
controllers 

• Upwind flux functions: flux difference splitting, flux vector splitting, 
artificially upstream flux vector splitting, Harten-Lax-van Leer contact, 
low dissipation flux splitting scheme, and others 

• Turbulence models: Spalart-Allmaras, Menter k-omega SST, Wilcox k- 
omega, detached eddy simulation, and others, including specified or pre- 
dicted transition 

• Implicit time stepping where the linear system is solved using either 
point-implicit, line-implicit, or Newton-Krylov (multigrid is also under 
active development) 


1 The multi-species, thermochemical non-equilibrium capability requires the high-energy 
physics library, which is only made available upon specific request and under certain condi- 
tions, see section 1.4 for details. 
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• Boundary conditions for internal flows and propulsion simulation includ- 
ing inlets, nozzles, and system performance 

• Grid motion: time- varying translation, rotation, and deformation includ- 
ing overset meshes and six degrees of freedom trajectory computations 

• Adjoint- and feature-based grid adaptation 

• Gradient based sensitivity analysis and design optimization via hand- 
coded discrete adjoint for reverse mode differentiation and automated 
complex variables for forward mode differentiation 

Before exploring more advanced applications (e.g., grid adaptation, moving 
grids, overset grids, design optimization), the user should become familiar with 
Fun3D’s basic flow solving capabilities and have appropriate computational 
capability available as indicated in the next section. 


1.2 Requirements 

The Fun 3D development team’s typical computing platform is Linux clusters; 
so this is the most thoroughly tested environment for the software. A number 
of users also run on other LINIX-like environments including Mac OS X M ; these 
platforms are supported as well. Users have also run on other architectures 
such as Microsoft Windows™-based PC’s; however, the team cannot provide 
explicit support for these environments. 

The user will need GNU Make and a Fortran compiler that supports at 
least the Fortran 95 standard. During configuration, the Fortran compiler is 
tested, and any newer Fortran features or extensions are detected are used 
to the greatest extent possible. A large number of compilers are tested by 
an automated build framework, including Intel®, Portland Group®, NAG®, 
Lahey/Fujitsu®, Cray®, Absoft®, IBM®, GFortran, and G95. 

While the code can be compiled to run on only a single processor, as demon- 
strated in the Quick Start section, most applications will require compiling 
against an MPI implementation and the ParMETlS domain decomposition 
library to allow parallel execution. 

The flow solver uses approximately 2.4 kilobytes of memory per grid point 
for a perfect gas RANS simulation with a loosely-coupled turbulence model. 
For example, a grid with one million mesh points would require approximately 
2.4 gigabytes of memory. Memory usage will increase slightly with the in- 
crease in the number of processors because of the increasing boundary data 
exchanged. Different solution algorithms and co-visualization options will also 
require additional memory. Typically, one CPU core per 50,000 grid points is 
suggested, where a 3D mesh of 20 million grid points would require 400 cores. 
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1.3 Grid Generation 


Fun3D has no grid generation capability. For internal development at NASA, 
the most common sources of 3D grids are VGRID (ViGYAN, Inc. and NASA 
Langley), SolidMesh/AFLR3 (Mississippi State), Pointwise (Pointwise, Inc.), 
and GridEx (NASA Langley). 

For 2D grids, the development team normally uses the AFLR2 software 
written by Prof. Marcum et al. at Mississippi State University Center for 
Advanced Vehicular Systems (CAVS) SimCenter. Scripts are available to fa- 
cilitate the use of this grid generator, but the generator itself must be obtained 
from Prof. Marcum. BAMG [4] is also used for 2D grid generation and adap- 
tation. 


1.4 Obtaining Fun3D 

Fun3D is export restricted and can only be given to a “U.S. Person,” which 
is a citizen of the United States, a lawful permanent resident alien of the U.S., 
or someone in the U.S. as a protected political asylee or under amnesty. The 
word “person” includes U.S. organizations and entities, such as companies or 
universities, see 22 CFR §120.15 for the full legal definition. Release of the 
high-energy, real-gas capability is further restricted because of International 
Traffic in Arms Regulations (ITAR). 

To request the Fun3D software suite, which will include the REFINE grid 
adaptation and mesh untangling library and the KNIFE cut-cell library, please 
use the website request form available at 

http : //f un3d.larc.nasa. gov/chapter- l.html#request_f un3d 

or send an email to Fun3D-Support@lists . nasa . gov containing the following 

information: 

• “U.S. person” to put on agreement form, i.e. , an institution or individual 

• Point of contact (if “U.S. Person” is not an individual) 

• Point of contact email address 

• Phone number, extension 

• FAX number (if available) 

• Address (PO boxes not allowed) 

• Proposed application 2 (optional) 

• How did you discover Fun 3D? (optional) 

2 The high-energy physics library that allows multiple species and non-equilibrium chem- 
istry are only included upon specific request— be sure to note that you desire access to 
this beta functionality as part of your application. Please include the phrase, “requesting 
high-energy gas libraries” . 
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We will forward your email to initiate a review by Langley software release 
authority (SRA) that verifies you qualify as a “U.S. Person.’' Depending on 
the SRA’s backlog, you will be sent a software usage agreement form in a 
week or two. Once a completed usage agreement form is received and the 
SRA notifies the Fun3D support team, the Fun3D support team will make 
arrangements for transfer of the Fun3D software suite. 
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2 Conventions 


This chapter discusses the coordinate system orientation and nondimension- 
alization used by Fun 3D. The nomenclature for this section is 


a 

= 

Speed of sound 

C 

= 

Sutherland constant 

e 

= 

Energy per unit mass 

f 

= 

Frequency 

h 

= 

Enthalpy per unit mass 

k 

= 

Thermal conductivity 

L 

= 

Length 

M 

= 

Mach number 

P 

= 

Pressure 

R 

= 

Gas constant 

Re 

= 

Reynolds number 

t 

= 

Time 

T 

= 

Temperature 

U , V, w 

= 

Cartesian components of velocity 

x,y,z 

= 

Cartesian directions 

a 

= 

Angle of attack 

P 

= 

Angle of sideslip 

7 

= 

Heat capacity ratio 

P 

= 

Viscosity 

P 

= 

Density 


where an asterisk (*) denotes a dimensional quantity. A subscript ref de- 
notes a reference quantity. For fluid variables, such as pressure, ref usually 
corresponds to the value ‘at oo’ for external flows or another condition for 
internal flows. The units of various reference quantities must be consistent. 
For example, if the reference speed of sound is defined in feet/sec, then the 
dimensional reference length, L* re f, must be in feet. In what follows, L* re f is 
the length in the grid that corresponds to the dimensional reference length; 
L re f is considered dimensionless. 

Fun3D’s angle of attack, sideslip angle, and associated force coefficients 
are based on a body-fixed coordinate system: 

• positive x is toward the back of the vehicle; 

• positive y is toward the right of the vehicle; and 


19 



• positive z is upward 

as shown in Fig. 3. This differs from the standard wind coordinate system by 
a 180 degree rotation about the y axis. The a and (3 flow angle conventions 
are shown in Fig. 4. 



Figure 3: Fun 3D body coordinate system. 


Z 



Figure 4: Fun 3D freestream flow angle definition. 


2.1 Compressible Equations 

x = x* / (L* re f/ L ref ) 

y = y / (L ref /Lref) 

z = z* / (L* ref /L ref ) 
t = t*a* ref / (L* ref / L re f) 


P = P* / P* ref Pref = 1 


20 


IVI 

= \V*\/a* ref 

\vL, 

= M re f 

u 

= u* / a* ref 

Href 

= M re f cos a cos P 

V 

= V*/ a* ref 

Href 

= —M re f sin (3 

w 

= W* / a* ref 

W r ef 

= M re f sin a cos /3 

p 

= P*/(P* relief) 

Pref 

= 1/7 

a 

= a* / a* ref 

d r ef 

= 1 

T 

= T*/T* re f 

T re f 

= 1 

e 

= Z*/( P \efa* 2 ref) 

H-ref 

= l/( 7 (7-l)) + M r 2 e/ /2 


To see how the nondimensional Navier-Stokes equations that are solved 
in Fun 3D are obtained from their dimensional counterparts, it is sufficient 
to look at the unsteady, one-dimensional equations for conservation of mass, 
momentum, and energy: 


dp* d(p*u*) 
dt* dx* 


d(p*u*) d 

dt* dx* 



4 „du* 
3^ dx* 


0 


de* 

dt* 


d 

dx* 


(e*+p*)u* 



dT* 

k*—— 

dx* 


0 


where k* is the thermal conductivity. For a thermally and calorically perfect 
gas, we also have the equation of state, the definition of the speed of sound, 
and the specific heat relation: 


a 


*2 


Vn T C v 


T* = P * 

p*R* 

7 R*T * (7 = c p */c v *) 

R* R* / c p * = (7 - l)/7 


The laminar viscosity is related to the temperature via Sutherland’s law 


p 


* 


P ref 


T * i 

ref + <-y 

T* + C* 



3/2 


where C* = 198.6°R for air. 

Substitution of the nondimensional variables defined above into the equa- 
tion of state and the definition of the speed of sound gives: 


T 



P 
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Sutherland’s law in nondimensional terms is given by 


= 1 + C*/T* ref 3/2 
h T + C */T* ref 

where C* is the Sutherland constant ( C * = 198. 6°R for air) and where T* re f 
is in degrees Rankine. 

Substitution of the dimensionless variables into the conservation equations 
gives, after some rearrangement, 

dp d{pu) = 
dt dx 


d(pu ) 
dt 


d_ 

dx 


pu +p~- 


4 Mr., 


ref du 

3 ReL dx 


e f 


= 0 


de 

dt 


d_ 

dx 


(e + p)u — - 


4 M re f du 


M, 


3 ReL. 


-pu 


ref 


dT 


p- 


ref 


dx Re Lr P r ( 7 - 1) dx 


= 0 


where P r is the Prandtl number (generally assumed to be 0.72 for air) 


Pr = 



k* 


and where ReL ref , the Reynolds number per unit length in the grid, corre- 
sponds to the input variable reynolds_number in the fun3d.nml hie. ReL ref is 
related to the Reynolds number characterizing the physical problem, ReL* ref 
by 


ReL , — 

^ ref 


P*ref\V*\ re f( L *ref/L re f) _ P \ ef \ V% ef L\ ef 1 


P 1 ref 


P ref 


J ref 


ReL % 


J ref 


2.2 Incompressible Equations 

x = x* / [L* ref ! L ref ) 

V = y / (L ref / L re f) 

z = z*/(L* ref /L ref ) 
t =t*\V*\ ref /(L* ref /L ref ) 


|E| 

= \v’W\ reI 

\VLf 

= l 

u 

= v/in,,, 

Uref 

= cos a cos (3 

V 

= «•/ lv"L, 

V ref 

= — sin f3 

w 

= <» 7 |r-| re/ 

W r ef 

= sin a cos f3 

p 

= V'/(P\et\ V '\lel) 

Pref 

= 1 
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For incompressible flows, Fun 3D does not model any heat sources. The 
temperature T* is constant and so is the viscosity /T. After dividing through 
by a constant reference density, the one-dimensional continuity and momentum 
equations are: 

du* _ 
dx* 


du* <9 [ , 2 p* 4p* ref du*] n 

( u H — — — = 0 

dt* dx* [ p* ref 3 p* re j dx* 

The fundamental difference between the nondimensionalization of the com- 
pressible equations and the incompressible equations is that the sound speed 
is used in the former and the flow speed in the latter. Substitution of the 
dimensionless variables defined above into the conservation equations gives, 
after some rearrangement, 

du 

dx 


du d 2 4 1 du 

dt ^ dx U ^ 3 Re L , dx 

L J-Jref J 


0 


where, exactly the same as in the compressible-flow path, the Reynolds number 
per unit length in the grid is 


P%e,\ V'LP’re, Re L% „ 

P* ref L re f 


2.3 Generic Gas Equations 

The generic gas path requires all reference quantities (velocity, density, temper- 
ature) be entered in the meter-kilogram-second (MKS) system. The transport 
property nondimensionalization includes the effects of rescaling using the grid 
length conversion factor. The nondimensionalization of other flow variables 
follows the practice used to derive the Mach number independence principle. 
Neither Mach number nor Reynolds number can be used to define reference 
conditions; these are derived from the fundamental reference quantities. The 
derived Reynolds number is relative to a one meter reference length. Tem- 
perature is never non-dimensionalized; it always appears in units of degrees 
Kelvin. 


p 

= P* / P* ref 

Pref 

[kg/nr 

u 

= U* IV* ref 

K, 

[m/s] 

V 

= V* IV* re f 

rn* 

1 ref 

[K] ' 

w 

= W* / V* ref 

T* 

L ref 

M 
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a = a* /V* re f 

P = P*/(p*refV* 2 ref) 
e = e* /V*l ef 
h = h* /V* 2 ref 
P =P*(T*)/p* ref v; ef L* ref 

2.4 Unsteady Flows 

One of the challenges in unsteady flow simulation is determining the nondi- 
mensional time step At. The number of time steps at that At necessary to 
resolve the lowest frequency of interest will impact the cost of the simulation 
and too large a At will corrupt the results with temporal errors. Time is 
non-dimensionalized within Fun3D by 

t = t* a* re f / (L* re f / L re f ) (compressible) 

t = t*\V*\ ref /(L* ref /L ref ) (incompressible) 

where, as in the previous sections, quantities denoted with * are dimensional. 

In all unsteady flows, one or more characteristic times t* c h. r may be identi- 
fied. In a flow with a known natural frequency of oscillation (e.g., vortex shed- 
ding from a cylinder), or in situations where a forced oscillation is imposed 
(e.g., a pitching wing), a dominant characteristic time is readily apparent. In 
such cases, if the characteristic frequency in Hz (cycles/sec) is f* chr , then 

t*chr = 1/F ch r 

In other situations, no oscillatory frequency may be apparent (or not known 
a priori). In such cases, the time scale associated with the time it takes for 
a fluid particle (traveling at a nominal speed of \V*\ re j) to pass the body of 
reference length L* re f is often used: 

t* chr = L\ ef /\V*\ ref 

The corresponding nondimensional characteristic time is therefore given by: 

tchr t chr® ref l re//-^re/) (compressible) 

tchr = t* chr \V*\ re f/(L* re f/L re f) (incompressible) 

Once the nondimensional characteristic t c j ir is determined, the user must 
decide on an appropriate number of time steps ( N ) to be used for resolving 
that characteristic time. Then the nondimensional time step may be specified 
as: 

A t = t chr / N 

The proper value of N must be determined by the user. However, a reasonable 
rule of thumb for second-order time integration is to take N = 200. Note that if 
there are multiple frequencies requiring resolution in time, the most restrictive 
should be used to determine At. 
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3 Boundary Conditions 

This chapter discusses the boundary conditions available in Fun3D. Table 1 
lists the integers used to specify Fun3D boundary conditions with a short 
description. Each grid description subsection in section 4 indicates how these 
integers are specified. Details of the boundary condition implementation are 
provided by Carlson. [5] Details of symmetry boundary conditions are provided 
in section 3.1. Some boundary conditions have required or optionally specified 
parameters defined in the &boundary .conditions namelist, see section B.4.16 
for further boundary condition details. 
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BC 

Table 1: 

Description 

Fun3D boundary conditions. 
Notes 

-1 

Overlap 

overset grid boundary 

3000 

Tangency 

zero normal velocity, specified via fluxes 

4000* 

Viscous 

explicitly set the no-slip condition 

5000 

Farfield 

Riemann invariants 

5026 

Extrapolate 

supersonic outflow, variables extrapolated from the interior 

5050 

Freestream 

external freestream, specified via fluxes 

5051* 

Back pressure 

specified static pressure (switches to extrapolation boundary 
condition in the presence of supersonic flow) 

5052* 

Mach outflow 

static pressure outflow boundary condition set via a specified 
subsonic Mach number (not for boundary layer ingestion) 

6021 

Symmetry plane 1 

symmetry enforced by replacing a;-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6022 

Symmetry plane 2 

symmetry enforced by replacing y-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6023 

Symmetry plane 3 

symmetry enforced by replacing 2 -momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6100 

Periodicity 

discrete periodicity, limited to nominally 2D grids extruded 
across n planes in a third dimension 

6661 

A'-symmetry plane 

enforces symmetry for x Cartesian plane 

6662 

F-symmetry plane 

enforces symmetry for y Cartesian plane 

6663 

A-symmetry plane 

enforces symmetry for 2 Cartesian plane 

7011* 

Subsonic inflow 

Subsonic inflow ( Pt,bc = Ptotal, plenum /p static, freestream} 
Tt,bc = ^ t otal ^l enU ral^ static ^f reeS t r earn) fof nozzle Or tunnel 

plenum ( M inflow < 1 ) 

7012* 

Subsonic outflow 

Subsonic Outflow {jpbc = Pstatic, inlet /Pstatic, freestream for l^“ 

let flow (does not allow for reverse or supersonic flow at the 
outflow boundary face) 

7021* 

Reaction control jet plenum models the plenum of a reaction control system (RCS) jet 

7031* 

Mass flow out 

specification of massflow out of the control volume 

7036* 

Mass flow in 

specification of massflow in to the control volume 

7100* 

Fixed inflow 

fixed primitive variables in to control volume 

7101* 

Fixed inflow profile 

specified profile 

7103* 

Pulsed supersonic inflow 

pulsing supersonic flow 

7104* 

Ramped supersonic inflow 

ramping supersonic flow 

7105* 

Fixed outflow 

specified primitive outflow conditions 


* See &boundary_conditions namelist in section B.4.16 to specify auxiliary information and for 
further descriptions. 
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3.1 X-Symmetry, F-Symmetry, and Z-Symmetry 

The symmetry condition in FUN3D enforces discrete symmetry. That is, if 
the mesh were mirrored about the symmetry plane and run as a full-span 
simulation, the residuals (and therefore the outputs, such as lift, drag, etc.) 
will be identical. The FUN3D automated tests include a case were a mirrored 
grid is compared to the symmetry boundary condition. Discrete symmetry is 
also enforced where multiple symmetry condition intersect (i.e., a corner of 
Y -symmetry and Z-symmetry). 

Specifically, the condition enforces: 

• Any points on a symmetry plane are first “snapped” to the average 
coordinate for that plane. Many grid generators will have some small 
amount of “slop” in their y-coordinates for points on a y-symmetry plane; 
FUN3D immediately pops all of the points onto the exact same plane, 
at least to double precision. 

• The residual equation corresponding to the momentum normal to the 
symmetry plane is modified to reflect zero crossflow (i.e., pv = 0 on a 
y-symmetry plane). 

• The least squares system used to compute gradients for inviscid recon- 
struction to the cell faces is augmented to include symmetry contribu- 
tions across the symmetry plane (s). 

• All gradients of the velocity normal to the symmetry plane (v for a 
y-symmetry plane) in the source terms for the turbulence models are 
zeroed out. Gradients of the tangential velocities are zeroed out normal 
to the symmetry plane (du/dy, dw/dy). 

• No convective flux of turbulence normal to the symmetry plane. 

• Grid metrics (e.g., areas, normals) are forced to be symmetric at sym- 
metry planes. 
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4 Grids 


This chapter explains how to supply the proper hie formats to Fun 3D, but 
does not cover how to create a mesh. See section 1.3 for grid generation 
guidance. Fun 3D supports a direct reader for many grid formats. The format 
of the grid is specified in the &raw_grid namelist. In addition to the directly 
read formats, translators are provided to convert additional grid formats into 
a format that can be read directly, see section 4.3. 

4.1 File Endianness 

The ordering of bytes within a data item is known as “endianness.” If the 
endianness of a hie is different than the native endianness of the computer 
then a conversion must be performed. The endianness of each grid hie format 
is described in section 4.2. If your compiler supports it, Fun 3D will attempt 
to open binary hies with a open (converts..) keyword extension. Consult the 
documentation of the Fortran compiler you are using to determine if other 
methods are available. For example, with the Intel® Fortran compiler, the en- 
dianness of hie input and output can be controlled by setting the FJJFMTENDIAN 
environment variable to big or little. 

4.2 Supported Grid Formats 

Fun 3D natively supports the grid formats summarized in Table 2. 


Table 2: File extensions. 


Format 

Grid files 

BC File 

AFLR3 

.ugrid 

.mapbc 

FAST 

.fgrid 

.mapbc 

FieldView 

.fvgrid_fmt 

.mapbc 


.fvgrid_unf 

.mapbc 

FUN2D 

.faces 

.mapbc 

VGRID 

.cogsg, .be 

.mapbc* 

FELISA 

.gri, .fro 

.bco 


* Same suffix, but GridTool format. 


The standard Fun 3D .mapbc hie format contains the boundary condition 
information for the grid. The hrst line is an integer corresponding to the num- 
ber of boundary groups contained in the grid hie. Each subsequent line in this 
hie contains two integers, the boundary face number and the Fun 3D bound- 
ary condition integer; these numbers may optionally be followed by a character 
string that specihes a “family” name for the boundary. The family name is 
required if the patch_lumping option (section B.4.2) is invoked to combine 


patches into fewer patch families. Below is a sample .mapbc hie illustrative for 
all grid formats except GridTool/VGRID, FELISA, and FUN2D, which are 
described later. 
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1 

6662 

box_ymin 

2 

5025 

box_zmax 

3 

5050 

box_xmin 

4 

5025 

box_ymax 

5 

5025 

box_zmin 

6 

5025 

box_xmax 

7 

3000 

wing_upper 

8 

3000 

wing_lower 

9 

3000 

wing_upper 

10 

3000 

wing_upper 

11 

3000 

wing_lower 

12 

3000 

wing_lower 

13 

3000 

wing_tip 


4.2.1 AFLR3 Grids 


AFLR3, SolidMesh, Pointwise, and GridEx can all produce this format and 
Fun3D ships with translators that convert Plot3D and CGNS grids to AFLR3 
format. The format is documented online at http : / / simcenter.msstate.edu/ 
docs/ solidmesh/ugridf ormat.html 

AFLR3 grid hie format types are indicated by hie suffixes. The formatted 
(plain text) style has a .ugrid suffix while other types vary according to endi- 
anness (see section 4.1) and binary type as shown in Table 3. The boundary 


Table 3: AFLR3 non-ASCII grid suffixes. 

Type Little endian Big endian 

Fortran Stream, C Binary .lb8. ugrid .b8. ugrid 

Fortran Unformatted .lr8. ugrid .r8. ugrid 

conditions are specihed via the standard Fun 3D .mapbc format. 

4.2.2 FAST Grids 

The .fgrid hie contains the complete grid stored in ASCII FAST format. 
The format is documented online at http://simcenter.msstate.edu/docs/ 
solidmesh/FASTf ormat.html The boundary conditions are specihed via the 
standard Fun 3D .mapbc format. 
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4.2.3 VGRID Grids 


The .cogsg file contains the grid nodes and tetrahedra stored in unformat- 
ted VGRID format. The VGRID cogsg files always have big endian byte 
order regardless of the computer used in grid generation. See section 4.1 for 
instructions on specifying file endianness. 

The .be file contains the boundary information for the grid, as well as a flag 
for each boundary face. For viscous grids with a symmetry plane, VGRID 
is known to produce boundary triangles in the .be file that are incompatible 
with the volume tetrahedra. Fun 3D provides a repair_vgridanesh utility to 
swap the edges of these inconsistent boundary triangles. If Fun 3D reports 
that there are boundary triangles without a matching volume tetrahedra, use 
this utility. 

VGRID has a different .mapbc boundary condition format. For each 
boundary flag used in the .be file, the .mapbc file contains the boundary type 
information. The VGRID boundary conditions are described at the website: 
http://tetruss.larc.nasa.gov/usm3d/bc.html. The Fun 3D boundary con- 
dition integers can also be used in place of the VGRID boundary condition 
integers. Internally, Fun 3D converts the VGRID boundary condition inte- 
gers to the Fun 3D boundary condition integers as indicated in Table 4. 

Table 4: Boundary type mapping between VGRID and Fun3D. 

VGRID FUN3D 

-1 -1 

0 5000 

1 6662 

2 5005 

3 5000 

4 4000 

5 3000 

44 4000 

55 3000 


4.2.4 FieldView Grids 

The ,fvgrid_fmt file contains the complete grid stored in ASCII FieldView 
FV-UNS format, and the ,fvgrid_unf file contains the complete grid stored 
in unformatted FieldView FV-UNS format. Supported FV-UNS file versions 
are 2.4, 2.5, and 3.0. With FV-UNS version 3.0, the support is only for the 
grid file in split grid and results format; the combined grid/results format 
is not supported. Fun 3D does not support the arbitrary polyhedron ele- 
ments of the FV-UNS 3.0 standard. For ASCII FV-UNS 3.0, the standard 
allows comment lines (line starting with !) anywhere in the file. Fun3D 
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only allows comments immediately after line 1. Only one grid section is al- 
lowed. The precision of the unformatted grid format should be specified by 
the f ieldview_coordinate_precision variable in the &raw_grid namelist, 
see section B.4.2. The boundary conditions are specified via the standard 
Fun 3D .mapbc format. 


4.2.5 FELISA Grids 

The .gri file contains the grid stored in formatted FELISA format. [6] The 
.fro file contains the surface mesh nodes and connectivities and associated 
boundary face tags for each surface triangle. This file can contain additional 
surface normal or tangent information (as output from GridEx or SURFACE 
mesh generation tools), but the additional data is not read by Fun 3D. The 
.bco file contains a flag for each boundary face. If original FELISA boundary 
condition flags (1, 2, or 3) are used, they are translated to the corresponding 
Fun 3D 4-digit boundary condition flag according to Table 5. Alternatively, 
Fun 3D 4-digit boundary condition flags can be assigned directly in this file. 


Table 5: Boundary type mapping between FELISA and Fun3D. 

FELISA FUN3D 

1 3000 

2 6662 

3 5000 


4.2.6 Fun 2D Grids 

The .faces file contains the complete grid stored in formatted Fun 2D format 
(triangles). Internally, Fun 3D will extrude the triangles into prisms in the 
^-direction and the 2D mode of Fun 3D is automatically enabled. Output 
from the flow solver will include this one-cell wide extruded mesh. 

Boundary conditions are contained in the Fun 2D grid file as integers 0- 
8. The mappings to Fun 3D boundary conditions are given in Table 6. If 
Fun 3D does not detect a .mapbc, it will write a .mapbc file that contains the 
default Table 6 mapping. If you wish to change the boundary conditions from 
the defaults based on the .faces file, simply edit them in this .mapbc file and 
rerun Fun 3D. The boundary conditions in the .mapbc file have precedence 
over the .faces boundary conditions. If you wish to revert to the boundary 
conditions in the .faces file after modifying the .mapbc, you can remove the 
.mapbc and rerun Fun3D. 
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Table 6: Boundary type mapping between Fun2D and Fun3D. 

FUN2D FUN3D 

0 3000 

1 4000 

2 5000 

3 -1 

4 4010 

5 4010 

6 5005 

7 7011 

8 7012 

4.3 Translation of Additional Grid Formats 

While Fun 3D supports the direct read of multiple formats, utilities are pro- 
vided to translate additional grid formats into a format that Fun 3D can read. 

4.3.1 PLOT3D Grids 

The utility plot3d_to_af lr3 converts a PLOT3D structured grid to an AFLR3- 
format hexahedral unstructured grid. The original structured grid must be 
3D multiblock http://www.grc.nasa.gov/WWW/wind/valid/plot3d.html (no 
iblanking) with the hie extension ,p3d for formatted ASCII or the the hie ex- 
tension .uf mt for Fortran unformatted. Only one-to-one connectivity is allowed 
with this option (no patching or overset). The grid should contain no singular 
(degenerate) lines or points. A neutral map hie with extension .nmf is also re- 
quired. This hie gives boundary conditions and connectivity information. The 
.nmf hie is described at http://geolab.larc.nasa.gov/Volume/Doc/nmf.htm. 

Note that the Type name in the .nmf hie must correspond with one of 
Fun3D’s BC types, plus it allows the Type one-to-one. If the Type is not 
recognized, you will get errors like: 

This may be an invalid BC index. 

An example .nmf hie is shown here for a simple single-zone airfoil C-grid 
(5 x 257 x 129) with six exterior boundary conditions and one one-to-one 
patch in the wake where the C-grid attaches to itself: 


Neutral 

Map File generated by the V2k software of 

NASA 

Langley's GE0LAB 

Block# IDIM 

JDIM KDIM 



i 

1 5 

257 129 



Type 

B1 FI SI El S2 E2 B2 F2 SI 

El 

S2 E2 Swap 
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1 tangency 1 
1 tangency' 

' f arf ield_extr ' 
' f arf ield_extr ' 
' one-to-one 1 
1 viscous_solid' 
' f arf ield_riem' 


1 3 1 257 1 129 

1 4 1 257 1 129 

1 5 1 129 1 5 

1 6 1 129 1 5 

111 5 1 41 1 1 1 5 257 217 false 

111 5 41 217 

12 1 5 1 257 


4.3.2 CGNS Grids 

Fun3D is distributed with a utility cgns_to_af lr3 that converts CGNS hies 
http://cgns.sourceforge.net/ to AFLR3 grids. This utility will only be 
built if Fun3D is conhgured with a CGNS library, see section A. 7. 12. Only 
the Unstructured type of CGNS hies are supported. The following CGNS 
mixed element types are supported: PENTA_6 (prisms), HEX_8 (hexes), TETRA_4 
(tets), and PYRAJ5 (pyramids). 

The CGNS hie must include Elementsvt nodes for all boundary faces (type 
QUAD_4 or TRI_3) to refer to the corresponding boundary elements. Otherwise, 
the utility cannot recognize what boundaries are present because it currently 
identifies boundaries via these 2D element types. The cgns_to_af lr3 utility 
requires that the BC elements be listed either as a range or a sequential list. 

It is also helpful to have separate element nodes for each boundary element 
of a given BC type. This way, it is easier to interpret the boundaries, i.e. , body 
versus symmetry versus farheld. Visualization tools, such as Tecplot™, can 
easily distinguish the various boundary condition groups as long as each group 
has its own node in the CGNS tree. Under BC_t, cgns_to_af lr3 reads these 
BC names, but ignores additional boundary data (e.g., BCDataSet, BCData). 


Table 7: Boundary type mapping between CGNS and Fun3D. 
CGNS FUN3D 


BCSymmetry Plane 
BCFarfield 
BCWallViscous 
BCWall 

BCWalllnviscid 

BCOutflow 

BCTunnelOutflow 

BCInflow 

BCTunnellnflow 


6661, 6662, or 6663 via prompt 

5000 

4000 

4000 

3000 

5026 

5026 

5000 

5000 


If the CGNS hie is missing BCs (no BC_t node), cgns_to_af lr3 still tries 
to construct the BCs based on the boundary face Element s_t information. If 
these boundary element nodes have a name listed in Table 7, a .mapbc hie 
will be written that contains the Fun3D boundary condition numbers. If the 
name is not recognized, you will see the message: 

WARNING: BC type ... in CGNS file not recognized. 
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in which case you will need to fix it by by editing the .mapbc file manually. 
Always check the .mapbc file after the utility has run, to make sure that the 
boundary conditions have all been interpreted and set correctly. If a trans- 
lation problem is observed, you should edit the .mapbc file before running 
Fun3D. 

4.4 Implicit Lines 

The standard implicit solution relaxation scheme in Fun3D is a point-implicit, 
which inverts the linearization of the residual at each node to compute an up- 
date to the solution. A line-implicit relaxation scheme can be used that inverts 
the linearization of a line of nodes simultaneously. Typically, lines are con- 
structed for the subset of nodes in the boundary layer to address the stiffness 
inherent in the Navier-Stokes equations on anisotropic grids. Therefore, the 
use of line- implicit relaxation may improve the convergence of viscous flow sim- 
ulations. These lines are used in conjunction with the standard point-implicit 
relaxation scheme. Detailed descriptions of both line and point relaxation 
schemes are provided by Nielsen et al. [7] Currently, every viscous boundary 
node must have one and only one associated implicit line. Lines of nodes 
are specified in a formatted file with the suffix ,lines_fmt that contains the 
definitions of lines emanating from viscous boundary nodes as a list of node 
numbers. The format of the ,lines_fmt file is 

[total number of lines] [total number of points in lines] 

[min points in a line] [max points in a line] 

[points in line 1] 

[first node of line 1] 

[last node of line 1] 

[points in line 2] 
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5 Flow Solver, nodet 

This chapter covers what is required to run an initial flow solution, how to 
restart a flow solution, and how to specify what outputs the solver nodet 
produces. 

5.1 Flow Solver Execution 

The grid and flow conditions are specified in the file f un3d.nml; see section B.4 
for the file description. If you configured Fun 3D without MPI, the executable 
is named nodet. If you configured Fun 3D with MPI, the executable is named 
nodet_mpi. Configuration and installation is explained in detail in section A. 
The executable nodet can be invoked directly from the command line, 

nodet [fun3d options] 

but the MPI version nodet _mpi will need to be invoked within an MPI envi- 
ronment. The most common method is via 

[MPI run command] [MPI options] nodet_mpi [fun3d options] 

The details of the MPI run command and MPI options will depend on the MPI 
implementation. The MPI run command is commonly mpirun or mpiexec. 
The MPI options may contain the number of processors -np [n] , a machine 
file -machinef ile [file] , or no local -nolocal. If a queuing system is used 
(e.g., PBS) this command will need to be run inside an interactive job or a 
script. See your MPI documentation or system administrator to learn the 
details of your particular environment. 

If you have provided a grid with boundary conditions and fun3d.nml, you 
will then see the solver start to execute. If an unexpected termination happens 
during execution, especially during grid processing or the first iteration, you 
may need to set your shell limits to unlimited, 

$ ulimit unlimited # for bash 
$ unlimit # for c shell 

A detailed description of the output files is given below. 

5.2 Command Line Options 

These options are specified after the executable. The majority of the command 
line options are functionality under development and there is work underway to 
migrate command line options to namelists. Namelists are the preferred input 
method. Command line options should be avoided unless they are the only 
way to activate the functionality you require. These commands are always 
preceded by -- (double minus). More than one option may appear on the 
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command line (each option proceeded by a -- ). You can see a listing of the 
available command line options in any of the codes in the Fun 3D suite by 
using the command line option --help after the executable name, 

. /nodet_mpi — help 

The options are then listed in alphabetical order, along with a short de- 
scription and a list of any auxiliary parameters that might be needed, and 
then the code execution stops. Specific examples of the use of command line 
options are found throughout this, and later, chapters. 

5.3 Output Files 

These are the output hies produced by the how solver, nodet. 

[project jrootname] .f low This hie contains the binary restart infor- 
mation and is read by the solver for restart computations. See the restart _read 
namelist variable in section B.4.13 to control restart behavior. 

[project_rootnamej_hist.dat This hie contains the convergence his- 
tory for the RMS residual, lift, drag, moments, and CPU time, as well as the 
individual pressure and viscous components of each force and moment. The 
hie is in Tecplot™ format. See section B.4.20 for an improved method to track 
forces and moments. 

[pro j ect rootname] subhist.dat For time accurate computations only. 
This hie contains the sub-iteration convergence history for the RMS residuals. 
The hie is in Tecplot M format. 

[project _rootname] .forces This hie contains a breakdown of all the 
forces and moments acting on each individual boundary group. The totals for 
the entire configuration are listed at the bottom. See section B.4.20 for an 
improved method to track forces and moments. 

5.3.1 Flow Visualization 

There are four basic categories of output: boundary data, sampling data (on 
entities such as planes, boxes and spheres), volumetric data, and slice data 
controlled by the namelists in Table 8. 

Each namelist has a corresponding frequency variable, A positive frequency 
will cause the output to be generated every frequency time step/iteration. A 
negative frequency will cause output to be written only at the end of a run. A 
zero frequency (the default) with produce no output. See the corresponding 
namelist descriptions for details. 
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Tabic 8: Solver output types. 

Type Namelist 


domain boundaries 
domain volume 
boundary slices 
various geometries 

point 


feboundary .output _var i abl e s 
fevolume.output .variables 
&slice_data 

&sampling_parameters and 
&sampling_output .variables 
&sampling_parameters and 
&sampling_output .variables 


section B.4.24 
section B.4.23 
section B.4.27 
section B.4.26 and 
section B.4.25 
section B.4.26 and 
section B.4.25 


5.3.2 Flow Visualization Output From Existing Solution 

If a Fun3D flow solution already exists, visualization files by setting steps 
= 0 in the &code_run_control namelist within the fun3d.nral hie and setting 
the restart_read variable to something other than ’off’. This will allow 
generation of visualization output without having to do additional timesteps 
or iterations. 
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6 Adjoint Solver, dual 

This section describes how to execute the adjoint solver, dual, directly. Typ- 
ically, dual is executed by scripts that manage the multiple steps required 
for design optimization (section 8) or grid adaptation (section 7). However, 
it may be necessary to run DUAL directly to diagnose problems or gain expe- 
rience during setup including determining input parameters and termination 
strategies. Fun3D is configured to compile dual by default. While the ad- 
joint method is available for most commonly used Fun3D capabilities, only a 
subset of Fun3D’s full capabilities are implemented in the adjoint solver. 

6.1 Convergence of the Linear Adjoint Equations 

The adjoint solution is dependent on the primal flow solution (and the con- 
vergence of the primal flow equations). While the primal solution may have 
converged enough to give acceptable force and moment results, the flow resid- 
uals might still be large, which can cause the adjoint solution scheme to di- 
verge. This divergence issue is most common in turbulent simulations. A 
divergent adjoint scheme can be improved in some circumstances with the 
— outer_loop_krylov command line option. It is critical to run the flow 
solver and the adjoint solver with the same governing equations and bound- 
ary conditions. 

The scaling of the adjoint residuals is different from the flow residuals 
and is dependent on the choice of the adjoint cost functions. The number of 
iterations steps and the residual tolerance stoppingvtolerance will need to 
be adjusted, see section B.4.13. The sensitivities should converge at the same 
rate as your functions (i.e., lift), but an adjoint with some algebraic error may 
still provide reasonable sensitivities for design and grid adaptation. 

6.2 Required Directory Hierarchy and Executing dual 

The executable dual can be invoked directly from the command line, 
dual [fun3d options] 

but the MPI version dualunpi will need to be invoked within an MPI envi- 
ronment. The most common method is via 

[MPI run command] [MPI options] dual_mpi [fun3d options] 

Any [fun3d options] provided to NODET that control the flow solver residual 
will also be required for the adjoint solver for a consistent adjoint solution and 
solution scheme. See the flow solver execution instructions for more details, 
section 5.1. 
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DUAL expects the cost function description ../rubber. data to be in the 
parent directory of the directory from which it is invoked. The input and 
flow restart hies are shared with NODET in the directory ../Flow/. The how 
solver must be run to completion, to provide a how restart hie, before dual 
is invoked. See Table 9 for the required hies and locations. 


Table 9: Adjoint solver DUAL directory hierarchy. 

Relative Path Description 

../Flow/ [pro ject_rootname] .flow Primal how solution (restart) 

../Flow/fun3d.nml Main input namelist hie 

../rubber. data Description of the adjoint cost function 


6.3 rubber. data 

The minimum required rubber. data for running the adjoint (and grid adap- 
tation) can be written with the command 

f3d function [cost function name] 

Available cost function names are discussed in section 8.1 and listed in Ta- 
ble 10. See section 8.6.2 for complete details on this hie format including the 
information required for design. The rubber. data reader requires the exact 
number of header lines. Be very careful when editing this hie. 

6.4 Output Files 

The adjoint solver will export visualization hies in the same manner as the 
how solver when requested, see section 5.3.1. 

[project jrootname] .adjoint This hie contains the binary restart in- 
formation and is read by the and adjoint solver for restart computations. 

[project _rootname] _hist.tec This hie contains the convergence his- 
tory for the RMS residual of the adjoint equations and CPU time. The hie is 
in the same Tecplot™ format as the how solver produces. History information 
is truncated when the adjoint solver is restarted. 
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7 Grid Adaptation 


Fun 3D implements metric-based adaptation, where grid adaptation is sepa- 
rated into two tasks. The first step is to construct a metric that describes the 
desired size and anisotropy of the adapted grid elements. The second step is 
to produce an adapted grid that is based on this metric. 

Feature-based adaptation constructs the metric based on properties of the 
flow solution. Adjoint-based adaptation constructs the metric from the flow 
and adjoint solutions to reduce estimated errors in a specified output function. 
The namelist feadapt unetric.construction (section B.4.30) for specifying de- 
tails of the metric. 

Fun3D supports a number of grid adaptation libraries. The namelist 
&adapt .mechanics (section B.4.31) specifies the grid adaptation library and 
its options. The refine library is distributed and installed with Fun3D by 
default. 


7.1 Geometry Specification and Grid Freezing for re- 
fine 

When adapting a grid with refine, all boundary faces must be specified as 
frozen or a geometry definition mush be provided via FAUXGeom. Use the 
default patch_lumping= ; ’none , in the &raw_grid namelist, as lumping will 
change boundary patch indexes making it more difficult to specify geometry. 


7.1.1 No geometry, where the surface nodes are frozen. 

refine cannot preserve the high aspect ratio structures within viscous layers, 
and so viscous layers must be frozen for a specified distance away from the 
surface to maintain grid quality. This is invoked with the adapt_freezebl 
command within the &adaptation_mechanics namelist, see section B.4.31 for 
more details. 

Additionally, specific surfaces that do not have a viscous boundary condi- 
tion can be frozen by listing the surface numbers (one per line) in a hie named 
[project_rootname] .freeze. For example, [project_rootname] .freeze that 
contains 

5 

7 


will freeze points on boundary patches 5 and 7. This is also useful for boundary 
surfaces that do not have an analytical definition handled by FAUXGeom. 
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7.1.2 FAUXGeom for Planar Boundaries 

For viscous problems, where the mesh on the complex geometry of the body 
is frozen, FAUXGeom can be used to provide an analytical definition of the 
farfield boundary surfaces. This allows adaptation to occur on the planar sur- 
faces of the mesh, even when the boundary layer mesh is frozen. This is a 
particularly important capability for symmetry planes. At present, FAUX- 
Geom can only handle planar surfaces. 

FAUXGeom reads the hie faux_input. Here is an example hie: 


4 

5 xplane -5.0 
3 yplane -1.0 
1 zplane 1.0 
16 general_plane 2.0 
0.707 0.707 0.0 

The hrst line is how many faux surfaces are being dehned. The subsequent 
lines have a face number, type of face, and a distance associated with the 
particular geometry. In this example, the hrst faux face dehned corresponds 
to surface 5 in the mesh and is a x = —5.0 constant plane. Faux faces are 
similarly dehned for the z and y planes of surfaces 3 and 1. Surface 16 is 
a plane perpendicular to a (0.707,0.707,0.0) normal that is located 2.0 away 
from the origin in the direction of the normal; the plane passes through the 
point (1.414,1.414,0.0). 

7.2 Performing Feature-Based Adaptation 

The &adapt_metric_construction variable adapt_f eature_scalar_f orm de- 
fines the operator that is applied to the adaptvf eature_scalar_key to com- 
pute an adaptation intensity. This intensity is raised to the adapt ^exponent 
power to produce a scaling of an isotropic element size estimate on the cur- 
rent grid. The anisotropy of the metric is introduced by the Hessian of the 
adapt _hessian_key variable. 

Set restart_read= ; ’ on J in section B.4.13 to read the how solution. Run 
NODET with the --adapt command line option in the directory with the how 
restart. The result will be a new grid and interpolated solution hie with 
the adapt.project project name. After adaptation, the how solver can now 
be restarted with this new grid and interpolated solution by changing the 
pro j ect_rootname. 

7.3 Performing Adjoint-Based Adaptation 

Adjoint-based adaptation requires that a how solution be calculated in the 
Flow directory and an adjoint solution be calculated in the Adjoint directory. 
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See section 6 for more information on obtaining an adjoint solution. The 
adjoint solution is based on the functional defined in rubber. data and this is 
the same functional targeted for grid adaptation. 

Adaptation is performed by executing DUAL with the command line op- 
tions — rad — adapt. The adjoint solver reads the fun3d.nml in the ../Flow 
directory), so this is the place to specify &adapt_metric_construction and 
feadapt .mechanics options. The freeze and FAUXGeom files are read in the 
current directory, Adjoint. 

The result will be a new grid and interpolated solution restart file in the 
../Flow directory and an interpolated adjoint restart in the Adjoint directory. 
The project name of these new files is adapt .project. 


7.4 Scripting Grid Adaptation 

The Fun 3D installation includes the f 3d script. To find the other components 
of the Fun 3D suite, the f3d script expects to be in the bin directory of the 
Fun 3D installation. Don’t copy or link f 3d from the bin directory. The input 
file case.specif ics is described in section 7.4.1. 

Execute the f 3d script in a directory that contains all of the the input files 
(e.g., grid, fun3d.nml, case.specif ics). The script will create the required 
Flow and Adjoint directories to run the case. It has the following commands, 


usage: f3d <command> 
<command> description 


start Start adaptation 

view Echo a single snapshot of stdout 

watch Watch the result of view 

shutdown Kill all running fun3d and ruby processes 

clean Remove output and sub directories 

function [name] write rubber. data with cost function [name] 


The command start begins adaptation by launching a background job. The 
commands view and watch allow the adaptation progress to be monitored. 
(Use Ctrl-C to escape the watch command.) The shutdown command kills 
all ruby (f3d) and Fun 3D jobs. The clean command removes the Flow and 
Adjoint subdirectories and the output log file. The function command with 
argument creates the rubber. data file to define the adjoint cost function. 


7.4.1 Input File case specifics for f3d Script 

The f3d script has one input file, named case.specif ics. Here is an example 
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root_project ' ' 
number_of _processors 2 
mpirun_cominand 'mpiexec' 
f irst_iteration 1 
last_iteration 10 

# Any text after a number sign is a comment. 

where the defaults are listed. Adaptation will be performed from the first grid 
adaptation iteration 1 to the last grid adaptation iteration 10. The string in 
quotes next to rootyproject is the project root name. A two digit iteration 
number will be appended to it. The project name for the first adaptation will 
be [root.project] 01 and the last will be [root_project] 10. All the hies 
required to run NODET and DUAL should be provided in the current directory 
and the grid filename should include the root project name and iteration num- 
ber, [rootyproject] 01. Flow and Adjoint subdirectories are created by the 
script during execution, and the input hies are placed in their correct location 
by the script. 

Command line options can be passed to the codes via, 

all_cl 1 ' 
f lo_cl ' ' 
adj_cl ' ' 
rad_cl ' ' 

where all_cl is provided to all codes, flo_cl is provided to NODET, adj_cl 
is provided to DUAL during the adjoint solve, and rad_cl is provided to DUAL 
during error estimation and adaptation. For example, the line 

adj_cl ' — outer_loop_krylov 1 

turns on Krylov projection wrapping to stabilize the adjoint solve. 

The main input hie fun3d.nml provided in the current directory can be 
modified by the following commands 

all_nl [' variable '] = value 
f lo_nl [' variable 1 ] = value 
adj_nl [' variable 1 ] = value 
rad_nl [' variable '] = value 

where all_nl changes fun3d.nml for all codes, flcunl for NODET, adj_nl for 
DUAL during the adjoint solve, and rad_nl for DUAL during error estimation 
and adaptation. An example is 

adj _nl [ ' steps ' ] =500 

adj_nl [ ' stopping_tolerance 1 ] =1 . Oe-12 
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where the termination criteria of the adjoint solver can be specified separately 
than the flow solver. 

The case_specif ics is actually executable Ruby code. This allows values 
to be computed or conditionally executed, but also require nested quotes for 
character strings, 

rad_nl [ ' adapt_complexity ' ] = 5000*iteration 
number_of _processors 128 if (iteration>5) 
all_nl [ ' f lux_construction ' ] = "'vanleer'" 
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8 Design Optimization 


The Fun3D design framework uses a gradient-based optimization procedure. 
One potential approach to obtaining the required sensitivity derivatives is 
a conventional forward mode of differentiation, such as finite-differencing, 
complex-variable formulations, operator overloading, or direct differentiation. 
Since the cost of these techniques scales directly with the number of input pa- 
rameters, these methods are most efficient for problems where the number of 
outputs is considerably larger than the number of inputs. For such problems, 
Fun3D provides a complex variable formulation as described in section 8.14. 
However, for most aerodynamic design problems, the converse is true; the 
number of design variables is typically much larger than the number of objec- 
tive functions and/or constraints. In this context, an adjoint, or reverse mode 
of differentiation is preferred. 

Fun 3D provides a discrete adjoint capability to efficiently determine the 
sensitivities required by a gradient-based design procedure. The adjoint ap- 
proach enables the user to compute sensitivity derivatives of an output function 
with respect to an unlimited number of design variables at a cost equivalent 
to a single additional flow solution. For a general review of sensitivity analysis 
techniques, see [8] and [9]. 

The adjoint approach used in Fun3D relies on discrete linearizations of the 
relevant components of the flow solver. Most of Fun3D’s compressible perfect 
gas and incompressible capabilities are accounted for within the adjoint-based 
framework. Discretely consistent sensitivities have been demonstrated for both 
steady and unsteady inviscid, laminar, and turbulent flows based on the one- 
equation model of Spalart and Allmaras. Grid topologies may contain any 
combination of element types and may also contain overset grid discretizations. 
Grids may be static, non-inertial, or may contain any combination of static, 
rigidly-moving, or deforming overset component grids. Both compressible and 
incompressible formulations are available. The most commonly-used boundary 
conditions are implemented in the adjoint framework, and a broad range of ob- 
jective/constraint functions is also available. However, the user is encouraged 
to review the latest release notes or contact Fun3D-Support@lists .nasa.gov 
to determine if a specific analysis capability is currently supported by the ad- 
joint implementation. For a detailed overview of the adjoint-based procedure 
used in Fun3D and examples of its use for design optimization, see [10] and 
the references contained therein. 

Users are encouraged to gain extensive experience using Fun 3D for anal- 
ysis purposes before attempting design optimization. This experience will aid 
in properly setting up optimization cases, understanding the steps involved, 
and interpreting the results. 

The adjoint-based algorithms are very efficient, but a typical optimization 
will still require the equivalent of 0 ( 20 ) typical analyses. Therefore, secur- 
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ing sufficient computational resources is critical to performing realistic high- 
fidelity design. It should also be noted that the various optimization packages 
supported by Fun 3D may behave very differently for a given design problem; 
moreover, the optimal algorithm is generally problem-dependent. 

At this time, the documentation provided here is aimed at design opti- 
mization of steady flows. The extension to simulations involving unsteady 
flows is available for general use (e.g., see [11]), but is not currently covered 
here. Please contact Fun3D-Support@lists.nasa.gov if interested in using 
this capability. 

8.1 Objective/Constraint Functions 

To perform a gradient-based optimization, the user must specify at least one 
objective function to quantify the merit of the configuration. In the Fun 3D 
design infrastructure, such objective functions may take a very general form as 
described here. Note that all of the supported optimization packages always 
seek to minimize the chosen objective function. Care should be taken to pose 
the objective function accordingly. Multiple outputs may be accounted for in 
a variety of ways. Constraints may be included implicitly within the objective 
function(s) as penalty terms. Explicit constraint functions may also be posed, 
as either equality or inequality constraints. 

Note that the primary limitation in posing the problem statement is the 
general ability of the chosen optimization package to handle the design prob- 
lem posed by the user. For example, the PORT optimization software does 
not support the use of explicit constraints. KSOPT is the only supported op- 
timization package that supports the use of more than one objective function; 
however, Fun 3D offers several approaches to scalarize multiple objectives for 
other packages. Multi-point design is also supported in several forms. See 
section 8.9 and section 8.10 for specific details on these capabilities. 

The Fun 3D flow and adjoint solvers do not distinguish between objective 
functions and constraints. The solvers themselves merely provide function 
values and their sensitivities for use during the optimization procedure. The 
actual optimization packages are the only components in the design framework 
that make a distinction between objective functions and constraint functions. 

8.1.1 Terminology 

It is useful to establish some basic terminology when composing the design 
problem statement. Within the Fun 3D design infrastructure, the user speci- 
fies one or more component functions based on typical solver outputs. These 
component functions are then combined to form a single composite function. 
Multiple component functions may be used to form composite functions, and in 
turn, multiple composite functions may ultimately be specified. The user then 
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classifies each composite function, designating it either an objective function 
or a constraint function. Again, this distinction is solely for the optimiza- 
tion algorithm; Fun 3D simply evaluates and linearizes each of the composite 
functions in a generic sense and provides them to the optimization scheme. 

The adjoint formulation requires a separate adjoint solution for each com- 
posite function. For example, a drag-minimization problem with an explicit 
lift constraint will generally require two adjoint solutions at each step of the 
design procedure (one based on drag and one based on lift). Rather than per- 
forming separate adjoint executions for each function, Fun3D’s adjoint solver 
is implemented such that multiple adjoint solutions may be computed simulta- 
neously by cycling through a series of right-hand side vectors. In this manner, 
much of the computational overhead associated with discretizing the adjoint 
system is amortized over the collection of specified functions, and each addi- 
tional function only increases the overall computational cost by approximately 
40%. See [7] for further details on this aspect of the implementation. 

8.1.2 Functional Form 

Composite functions take the following general form in Fun3D: 


Here, the index Jj corresponds to the number of individual component func- 
tions comprising composite function i. The factor c Oj represents a user-specified 
weighting coefficient in the summation; Cj is a Fun 3D scalar output quantity, 
C* is a user-specified target value for that output quantity, and pj is a user- 
specified exponent. The currently available Fun 3D output functions that may 
be posed as Cj are listed in Table 10. Though not explicitly represented in 
Eq. 1, the implementation also allows the user to only use specific boundary 
contributions to Cj and not all boundaries if desired. This could be used to 
focus the optimization function on forces acting on the wing or tail only. Note 
that when composing an objective or constraint function it is often helpful 
to scale the expected value to an 0(1) quantity. This can be readily done 
using the ujj factor. Additional details relevant to more complex functions are 
covered in section 8.2. The specific input mechanism for providing each of 
the component/composite function parameters will be discussed at length in 
section 8.6.2. 

To demonstrate the use of the general functional form given by Eq. 1, 
several examples are given here: 

Unconstrained Drag Minimization For an unconstrained problem in 
which the user wishes solely to minimize drag, one potential approach might 



( 1 ) 
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Table 10: 

Keyword 

Objective/constraint component function keywords. 
Function 

cl, cd 

Lift, drag coefficients 

clp, cdp 

Lift, drag coefficients: pressure contributions 

civ, cdv 

Lift, drag coefficients: shear contributions 

cmx, cmy, cmz 

x/y/z-axis moment coefficients 

cmxp, cmyp, cmzp 

x/y/z-axis moment coefficients: pressure contributions 

cmxv, cmyv, cmzv 

x/y/z-axis moment coefficients: shear contributions 

cx, cy, cz 

x/y/z-axis force coefficients 

exp, cyp, czp 

x/y/z-axis force coefficients: pressure contributions 

cxv, cyv, czv 

x/y/z-axis force coefficients: shear contributions 

powerx, powery, powerz x/y/z-axis power coefficients 

eled 

Lift-to-drag ratio 

f om 

Rotorcraft figure of merit 

propeff 

Rotorcraft propulsive efficiency 

rtr_thrust 

Rotorcraft thrust function 

pstag 

RMS of stagnation pressure in cutting plane disk 

boom_targ 

Near-field p/poo pressure target 

sboom 

Coupled sBOOM ground-based noise metrics 

ae 

Supersonic equivalent area target distribution 

pressJbox 

RMS of pressure in user-defined box, also pointwise dp/dt, dp/dt 

cpstar 

Target pressure distributions 


be to specify a single composite function consisting of a single component 
function with uj\ = 1.0, Cj = cd, C / = 0.0, and pi = 2. In this manner, the 
objective function is simply 


/ 



( 2 ) 


where the quadratic form has been chosen to provide a convex function space. 


Drag Minimization with Lift Penalty To add an interior penalty term 
accounting for a lift equality constraint of 0.5, one might instead use two 
component functions within the same single composite function where = 
10.0, u >2 = 1.0, Ci = cd, C 2 = cl, C* = 0.0, C 2 = 0.5, and pi = P 2 = 2. These 
parameters yield 

/ = 10 Cl + (C L - 0.5) 2 . (3) 

In this case, any deviation of the lift coefficient from its target value of 0.5 
will “penalize” the objective function. The weighting parameters c Uj have been 
selected based on typical magnitudes of Cd and Cl, so as to produce roughly 
equivalent contributions to the objective function. Note that the choice of 
these weighting parameters is heuristic in nature and often troublesome in 
practice. 
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Drag Minimization with Explicit Lift Constraint In this example, the 
lift constraint Cl = 0.5 is instead posed as an explicit constraint for the opti- 
mizer. Here, two composite functions are formed, each with a single component 
function. First, an objective function is specified as in Eq. 2 with uj\ = 1.0, 
C\ = cd, Ci = 0.0, and p\ = 2. As before, this yields 

h = Cl (4) 

However, an additional composite function for the lift constraint is also spec- 
ified with lui = 1.0, C i = cl, Ci = 0.5, and pi = 1, which gives 


h = C L . (5) 

This explicit form of the lift constraint is generally preferred in practice. 

8.2 Some Details on Specific Objective/Constraint 
Functions 

Many of the scalar functions shown in Table 10 and designed to be used as the 
term Cj in Eq. 1 are straightforward. For example, the keyword cd is sufficient 
to characterize a drag-based component function. However, some of the scalar 
functions listed in Table 10 require the user to be aware of specific requirements 
and/or to provide additional auxiliary data. In this section, scalar functions 
requiring further data and/or explanation are covered. 

8.2.1 Lift-to-Drag Ratio (Keyword: clcd) 

This function must be specified with a 0 for its boundary index, i.e. , it must be 
applied to the entire configuration and is not available for individual boundary 
patches. It is defined as 

S=% ( 6 ) 

C'D 

8.2.2 Rotorcraft Figure of Merit (Keyword: f om) 

This function is defined as 


/ 


Cl 

2 C'li z 


( 7 ) 


Note that this functional form assumes that the rotor axis of rotation is in 
the +z direction. The definition also represents the square of the traditional 
Figure of Merit function. See [12] for a motivation for this modified form. 
This function must be specified with a 0 for its boundary index, i.e., it must be 
applied to the entire configuration and is not available for individual boundary 
patches. 
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8.2.3 Rotorcraft Propulsive Efficiency (Keyword: propeff) 

This function is defined as 


/ 


-C z 

c Mz ' 


( 8 ) 


Note that this functional form assumes that the rotor axis of rotation is in 
the +z direction. The minus sign has been introduced to yield a positive 
efficiency since Cm z is negative. This function must be specified with a 0 for 
its boundary index, i.e., it must be applied to the entire configuration and is 
not available for individual boundary patches. 


8.2.4 Rotorcraft Thrust (Keyword: rtr thrust) 

This function is defined as the force normal to the plane of a rotor system: 

f = C L cos (9 t ) - C D sin(0 T ) (9) 

where the angle from + ^-direction 9 t in radians is the variable thrust_angle 
that must be set in the source hie LibF90/custom_transf orras.f 90. 


8.2.5 RMS of Stagnation Pressure (Keyword: pstag) 

This function computes the RMS of stagnation (total) pressure in a circu- 
lar disk that passes through the grid in a specified location and orientation. 
This is commonly employed to quantify engine inlet distortion. The user must 
specify the variables in the &pstag_function namelist within fun3d.nml. See 
section B.4.37 for details related to this namelist. This function is only avail- 
able for compressible hows. 

8.2.6 Near-field p/poo Pressure Target (Keyword: boom_targ) 

This function allows inverse design of near-held pressure signatures, which is a 
commonly used tactic for creating low sonic boom configurations. This func- 
tion is only available for compressible hows. The user specihes yz-coordinate 
pairs through which rays are passed parallel to the x-axis. Off-body pressure 
distributions in the vicinity of an aircraft are nominally oriented parallel to 
the freestream velocity vector. In the case of a nonzero angle of attack, the 
rays are rotated about a user-specihed center of rotation to align them with 
the freestream direction. The user also provides the minimum and maximum 
x-extent for the rays. A user-specihed number of points are evenly distributed 
along each ray and the grid element containing each point is identihed. See 
section B.4.33 for guidance on the required namelist inputs. 

The functional form is given by 
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( 10 ) 


where p is the local static pressure. The summation takes place over all points 

in the rays defined by the user, and the values of p are evaluated at the 

* 

centroids of the enclosing elements. The values of cu* and are user-supplied 


poiutwise weighting coefficients and target values of p/poo, respectively, which 
must be provided in a file named pressure_target.dat. If this file is not 
present, the target values of p/poo are set to 1.0 and the weighting coefficients 
are set to 1.0. Note that with the above functional form, the target and 
exponent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively. 

A template for pressure_target.dat is typically generated by first ex- 
tracting a set of p/poo distributions for a known configuration by running the 
optimization driver with Operation to perform set to 1 (“Analysis only”) 
in ammo. input. Note that the input value weight must be set to .true, 
and the desired ray extraction (y, z ) coordinate pairs must be specified in the 
&sonic_boom namelist in fun3d.nml. This operation produces a file named 
pressure_signatures.dat, which uses the same file format intended for the 
pressure_target.dat target input file. (Note that the file format is amenable 
to Tecplot™ usage.) The user may then use the pressure_signatures.dat 
file to develop a pressure_target.dat input file by modifying the existing 
pressures to reflect their target values as desired. Note that by specifying 
weight=.true . in the &sonic_boom namelist, a column of data representing 
pointwise weighting coefficients (all initially set to 1.0) will be provided in 
pressure_signatures.dat. This column of data is required to be present in 
pressure_target.dat. The individual weights may be left as 1.0, or they 
may be modified on an individual basis to optionally weight a specific region 
of the signature more or less in the final objective function. A brief example 
of this file format for a case involving two off-body signatures is shown below. 
Note that target distributions need not have the same number of locations as, 
nor line up with, the eventual sampling locations along the extraction rays. 
Fun3D will linearly interpolate between input target values to obtain values 
at the sampling locations. 


VARIABLES = "x" , "y" , "z", "p/pinf", "weight" 
zone t="Signal 1" 

-0 . 500E+01 0 . 100E-11 0 . 826E+00 0.110010E+01 0.100E+01 
-0 . 472E+01 0 . 100E-11 0.835E+00 0.110011E+01 0.100E+01 
-0 . 415E+01 0 . 100E-11 0 . 855E+00 0.110012E+01 0.100E+01 
-0 . 354E+01 0 . 100E-11 0.876E+00 0.110016E+01 0.100E+01 
zone t="Signal 2" 

-0 . 500E+01 0 . 100E-11 0 . 182E+01 0.102008E+01 0.100E+01 
-0 . 472E+01 0 . 100E-11 0.183E+01 0.102008E+01 0.100E+01 
-0 . 414E+01 0 . 100E-11 0 . 185E+01 0.102009E+01 0.100E+01 
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-0 . 356E+01 0 . 100E-11 0.187E+01 0.102012E+01 0.100E+01 
-0 . 335E+01 0 . 100E-11 0.188E+01 0.105013E+01 0.100E+01 
-0 . 320E+01 0 . 100E-11 0.188E+01 0.105014E+01 0.100E+01 
-0 . 264E+01 0 . 100E-11 0.190E+01 0.105017E+01 0.100E+01 

8.2.7 Coupled sBOOM Ground-Based Signatures, Noise Metrics, 
and Equivalent Areas (Keyword: sboom) 

This option uses the adjoint capability of the Burgers equation boom prop- 
agation code SBOOM [13] to inversely design ground pressure signatures, 
optimize a ground-based noise metric, or match equivalent area distributions. 
[14-16] Fun 3D must be configured and built with the sBOOM library as 
described in section A. 7. 13 to use this capability. 

In the coupled Fun3D-sBOOM implementation, Fun3D is responsible 
for computing pressure signals in the immediate vicinity of an aircraft (typi- 
cally within 10 body lengths). The sBOOM tool then propagates these dis- 
turbances to the ground using an augmented Burgers equation that considers 
effects such as non-linearity, thermo-viscous absorption, and any number of 
molecular relaxation phenomena during the propagation of waveforms through 
the atmosphere. In this manner, the user can directly simulate ground-based 
noise metrics such as A-weighted loudness or compute other loudness measures 
(e.g., Perceived Level) from the computed ground signatures. In a similar fash- 
ion, a coupled adjoint problem is used to determine the discrete sensitivities 
of the ground-based metrics with respect to any of Fun3D’s typical design 
parameters which may then be used to optimize the configuration. 

SBOOM can generate off-track signatures based on ray theory using user 
input azimuthal angles. SBOOM can also predict the sonic boom signatures 
in the presence of wind, turn rate (changing heading angle), climb rate, climb 
angle, and acceleration (dMach/dt). During maneuvering flight, boom focus- 
ing is possible. The current version SBOOM in not able model focusing and 
will exit with an appropriate message if focusing occurs. 

Equivalent area distributions are computed with reversed augmented Burg- 
ers equation (when rs< (alt— hg)) or a direct conversion of off-body pressures 
(when rs> (alt— hg)). This is different than the Mach cut equivalent area 
matching approach in section 8.2.8. The discrete sensitivities of the difference 
between a target and the computed equivalent areas are provided to Fun 3D. 
The target area is specified with the target.dpress and target_xx variables 
in the fesboom namelist. 

The user must provide inputs relevant to the nearfield pressure signal ex- 
traction (see section B.4.33) as well as parameters specific to the sBOOM 
library (see section B.4.34). Note that when the sboom keyword is used as 
the component function name, the actual form of the objective/constraint 
component function is determined entirely within SBOOM. In this case, the 
values of u, C*, and p in Eq. 1 are ignored. This function is only available for 
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compressible flows. 


8.2.8 Supersonic Mach Cut Equivalent Area Distribution 
(Keyword: ae) 

This function aims to match a target Mach cut equivalent area distribution for 
supersonic flows. The Mach cut equivalent area distribution is directly com- 
puted from surface pressures and geometry for this function. This is a different 
approach than the equivalent area computation of sBOOM in section 8.2.7. 
The function is defined as 


where N represents the total number of longitudinal stations used to sample 
the solution and geometry for the current azimuth, and L,- and Vi are the lift 
and volume contributions, respectively, to the current equivalent area. The 
term A* represents the user-supplied target equivalent area distribution. The 
uji enables the user to locally weight individual segments of the distribution 
if desired. Note that with the above functional form, the target and expo- 
nent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively. 
This function is only available for compressible flows, and the configuration is 
assumed to align with the x-axis. 

Any number of desired azimuthal (centerline/off-track) locations may be 
specified and used as individual component functions. The user must pro- 
vide the data indicated in the &equivalent_area namelist in fun3d.nml as 
described in section B.4.35. A centerline symmetry plane may be used to 
reduce computational expense; in this case, the cutting planes at each longitu- 
dinal station will be correctly accounted for on the virtual side of the aircraft. 
A hie ae_target.dat must also be provided, which describes the (optionally 
weighted) target equivalent area profiles. 

A template for ae_target.dat is typically generated by first extracting a 
set of equivalent area distributions for a known configuration by running the 
optimization driver with Operation to perforin set to 1 (“Analysis only”) in 
ammo. input. This operation will produce a Tecplot™ hie [projectxrootname] 
_ae.dat which uses the same hie format intended for the target input hie 
ae_target.dat. The user may then use the [pro j ect_rootname] _ae.dat hie to 
develop a ae_target.dat input hie by modifying the existing equivalent areas 
to rehect their target values as desired. Note that the hie [project_rootname] 
_ae.dat contains a column of data representing the pointwise weighting coeffi- 
cients Ui (all initially set to 1.0). This column of data is required to be present 
in ae_target.dat. The individual weights may be left as 1.0, or they may be 
modified on an individual basis to optionally weight a specihc region of the 
distributions more or less in the final objective function. A brief example of 


N 



( 11 ) 
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this file format for a case involving three azimuthal signatures is shown below. 
Note that target distributions need not have the same number of locations as, 
nor line up with, the longitudinal sampling locations. Fun3D will linearly 
interpolate between input target values to obtain values at the sampling lo- 
cations. Also note that in the input hie ae_target.dat, the second and third 
columns of the format are ignored. 


VARIABLES = "x" , "V", "L" , "Ae", "weight" 
zone t="Ae Function 1" 


-0 . 01000E+00 
0 . 13839E+01 
0 . 27678E+01 
0 . 41517E+01 


0 . 00000E+00 
0 . 25482E-01 
0 . 47548E-01 
0 . 76165E-01 


0 . 00000E+00 
-0 . 26289E-02 
-0 . 64155E-02 
-0 . 10361E-01 


0 . 00000E+00 
0 . 22853E-01 
0.41133E-01 
0 . 65804E-01 


zone t="Ae Function 2" 


0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0. 10000E+01 


-0 . 01000E+00 
0 . 14018E+01 
0 . 28036E+01 
0 . 42054E+01 
0 . 56072E+01 
0 . 98126E+01 


0 . 00000E+00 
0 . 25700E-01 
0.48215E-01 
0 . 7T379E-01 
0 . 11457E+00 
0 . 30728E+00 


0 . 00000E+00 
-0 . 26610E-02 
-0 . 64628E-02 
-0 . 10358E-01 
-0 . 14045E-01 
-0 . 25T26E-01 


zone t="Ae Function 3" 


-0 . 01000E+00 
0. 14155E+01 
0 . 28310E+01 
0 . 42465E+01 


0 . 00000E+00 
0 . 26009E-01 
0.48902E-01 
0 . 78591E-01 


0 . 00000E+00 
-0 . 26166E-02 
-0 . 62883E-02 
-0 . 10011E-01 


0 . 00000E+00 
0 . 23039E-01 
0 . 41752E-01 
0 . 67020E-01 
0 . 10052E+00 
0 . 28156E+00 

0 . 00000E+00 
0 . 23392E-01 
0 . 42614E-01 
0 . 68579E-01 


0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0 . 10000E+01 
0. 10000E+01 

0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0. 10000E+01 


Finally, the solver will also provide the user with a Tecplot lM output hie 
[project_rootname] _ae_cuts_i.dat for the ith specihed equivalent area func- 
tion. These hies contain the actual cross-sectional slices of the aircraft that 
were generated for each azimuthal function. 


8.2.9 RMS of Pressure in User-Defined Box, Pointwise dp/dt , 
dp/dt (Keyword: press box) 

This function computes the RMS of a quantity in Cartesian region, which is 
typically used to indicate a region of the how is important for grid adaptation 
or that fluctuations in a region should be minimized in a design. These func- 
tions rely on the inputs associated with the &press_box_function namelist; 
see section B.4.36 for details. The function may be composed of the RMS 
value of the pressure within a user-defined box in the domain, or for unsteady 
simulations, the time derivative of pressure or density (for compressible hows) 
at a single grid point. 


8.2.10 Target Pressure Distributions (Keyword: cpstar) 

Fun 3D has an inverse design capability where the objective function may 
be composed of target pressure distributions. The file containing the jth 
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target distribution must be named cpstar.data.j. However, setup is te- 
dious, primarily due to the difficulty in specifying pressure distributions on 
a three-dimensional configuration. If this capability is of interest, please con- 
tact Fun3D-Support@lists.nasa.gov for more detailed guidance. 

8.3 Geometry Parameterizations 

In order to perform shape optimization, Fun3D must be provided with a 
set of design variables describing the geometric shape of the configuration. 
Fun3D is currently set up to interface directly with geometry parameteriza- 
tions provided by MASSOUD [17], Bandaids [18], or Sculptor M . MASSOUD 
and Bandaids are software packages developed by Jamshid Samareh of NASA 
Langley (Jamshid.A.Samareh@nasa.gov). Users should contact him for copies 
of the software; tutorial information for these tools is available on the Fun3D 
website. These packages allow the user to parameterize completely arbitrary 
shapes using a free-form deformation technique. The packages are very ef- 
ficient, robust, and also provide analytic Jacobians of the parameterization, 
which are necessary for FuN3D-based design. Sculptor M is a popular commer- 
cial package developed by Optimal Solutions and also provides the necessary 
data for FuN3D-based design. Note that any combination of parameteriza- 
tions based on these tools may be used within the context of a single optimiza- 
tion. For example, the planform of a wing or tail surface may be best treated 
using MASSOUD, while Bandaids or Sculptor M may be most appropriate for 
a wing-body fillet region or a feature such as a fuselage protuberance. Finally, 
the user may also use a parameterization scheme of their choosing; see section 
section 8.3.4 for further details. 

8.3.1 Surface Grid Extraction 

To parameterize a surface grid using any of the above tools, it must first be 
extracted to a Tecplot™ file. To do this, add a &massoud_output namelist 
to fun3d.nml to group all of the required boundary patches for a body to be 
parameterized into a single body (see also section B.4.32): 

&massoud_output 
n_bodies = 2 
nbndry(l) = 6 
boundary_list (1) = '3-8' 
nbndry(2) = 3 

boundary_list (2) = '9,10,12' 

/ 

Note that the boundary indices shown here must reflect any patch lump- 
ing that may have been requested in the &raw_grid namelist (see also sec- 
tion B.4.2). A single iteration of the flow solver should now be executed 


parameterize 2 bodies: wing and tail 

# of bounds that comprise wing 
wing bounds (account for lumping!) 

# of bounds that comprise tail 
tail bounds (account for lumping!) 
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with the — write_massoud_f ile command line option. This will generate a 
[pro j ect_rootname] _massoud_bndry#.dat hie for each of the boundary groups 
present in the &massoud_output namelist. These hies contain the information 
necessary to parameterize the surface grid using any of the aforementioned 
tools. See the documentation for those packages for further instructions on 
how to construct the actual parameterization. 

8.3.2 Access to Executables 

If MASSOUD, Sculptor™, or a user-dehned executable is being used for param- 
eterizations, the executable for those packages must be available in the runtime 
PATH. The executables for MASSOUD and Sculptor™ must be named massoud 
and sculptor, respectively. If using a user-dehned parameterization package 
(see section 8.3.4), the executable must be named according to the input pro- 
vided in ammo. input (see section 8.5.1). The optimization driver supplied with 
Fun3D will attempt to call these executables if such parameterization types 
are present. If Bandaids are being used, no additional executables must be 
supplied; all Bandaid evaluations are handled internally by Fun3D. 

8.3.3 Notes on Using Sculptor™ 

If Sculptor M is being used, Fun3D will invoke Sculptor M in batch (non-GUI) 
mode during the course of the optimization. However, current versions of 
Sculptor lM will still attempt to communicate with an X server, even when run 
in this fashion. If the system does not run an X server (such as compute nodes 
on a cluster), then a fake X server such as Xvfb is recommended. You will 
need to execute the fake server prior to running the design optimization. For 
example, a run script may have the following commands: 

Xvfb : 1 & 

export DISPLAY=:1.0 # for bash 

setenv DISPLAY : 1 . 0 # for c shell 

[any command that uses Sculptor] 

The syntax here may vary; if this does not allow the optimization driver to 
run Sculptor M in batch mode successfully on the system, the user should get 
in touch with Sculptor M support for assistance. 

In addition, the parameterization of all bodies treated using Sculptor™ 1 
must be bookkept within a single set of Sculptor M input hies. For example, 
in the wing-tail example above, both bodies must be contained in a single in- 
stance of Sculptor M hies. Therefore, the &massoud_output namelist described 
above should group all of the desired boundaries necessary to describe the 
geometry(s) of interest into a single body: 
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&massoud_output 
n_bodies = 1 
nbndry(l) = 9 


wing and tail grouped into a body 
# of tail and wing bounds 
wing and tail boundaries 


boundary_list (1) = '3-10,12 


/ 


Each of the desired bodies may be worked on independently within Sculp- 
tor, but they must ultimately appear as a single body to Fun3D. 

8.3.4 Using Other Parameterization Packages 

Fun 3D provides a generic interface for user-defined external geometric pa- 
rameterization packages. The user-defined tool must provide the surface mesh 
coordinates as a function of some vector of design variables for the body of 
interest. The partial derivatives of these coordinates with respect to the design 
variables must also be supplied. See [19] for an example of such an approach. 

To invoke a user-defined parameterization package for one or more bodies 
present in the simulation, the user must tag individual bodies appropriately 
(see section 8.6.2) and provide the executable name to be invoked by Fun3D’s 
design driver at run-time via the input deck ammo. input (see section 8.5.1). 
This may be a binary executable or simply a script that invokes other user- 
defined operations that may be necessary to evaluate the parameterization and 
its sensitivities. 

When Fun 3D requires an evaluation of the user-defined parameterization 
for a body (or its sensitivities), it will first write a file named custoraDV.i, where 
the i suffix corresponds to the body index for which Fun 3D is requesting 
updated surface data. The format of the customDV.i hie is as shown below. 

#User defined design variables 
#Number of DVs 


1 . 907460000000000E+00 
0 . 000000000000000E+00 
-0 . 002469800000000E+00 

The Erst two lines are comment lines, and the third specifies the total number 
of design variables in the parameterization for the current body (whether the 
user may have designated some active and others inactive in rubber. data; see 
section 8.6.2). The remaining lines in the hie contain the current value of each 
design variable, with one value per line. 

After writing the customDV.i hie, Fun 3D will then invoke the user-specihed 
executable command provided in ammo, input. Fun 3D will append a space and 
a single integer to this executable command, where the integer corresponds to 
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the body index for which Fun 3D requires an evaluation of the parameteriza- 
tion. The user-provided executable (or script) must be capable of parsing this 
integer command-line option in order to process the requested body. 

After the external package has completed the evaluation of the parameteri- 
zation and its sensitivities, the data must be supplied to Fun 3D via a Tecplot™ 
hie named model. tec. i.sdl, where the integer i in the filename represents the 
current body index. The format of this hie must be as follows: 

TITLE = "PARAMETERIZATION DATA" 

VARIABLES = "X" "Y" "Z" "ID" "XDl" "YD1" "ZDl" "XD2" "YD2" "ZD2" "XD3" "YD3" "ZD3" 

ZONE T = groupO, I = 4, J = 1, F=FEP0INT 

0.0 1.0 0.0 235 1.234 -23.0 892.1 -23.0 82.123 -90.2 -905.2 857.12 348.2 
1.0 1.0 0.0 872 4.14 -0.123 -0.324 23.13 2978.2 -0.114 -982.4 -3.22 0.1185 
1.0 0.0 0.0 912 -0.34 0.938 8.45 78.23 -35.2 -0.023 8.32 -0.009 -0.92 
0.0 0.0 0.0 455 9.01 -8.23 -0.456 2.56 1.21 0.0 -0.091 -1.22 0.0088 
12 3 4 

The trivial (and completely contrived) example shown here provides sur- 
face mesh point locations and the corresponding sensitivities for a single quad 
element parameterized by three design variables. The title in the hrst line may 
contain anything the user desires. The variables identified in line 2 represent 
the x-, y-, and z-coordinates for the current surface mesh point, the node in- 
dex in the global grid for the current surface mesh point, and the sensitivity 
derivatives of the x-, y-, and z-coordinates of the current surface mesh point 
with respect to each of the design variables provided by Fun 3D in customDV.i 
above. The hie should contain a single zone, indicated by the third line of the 
example hie shown. Here, the zone title specihed by T = may be anything the 
user desires. The I = value corresponds to the number of surface mesh points 
for the current body, while the J = value specihes the number of surface ele- 
ments (triangles or quads) contained in the surface mesh for the current body. 
Fun 3D will only read the I = value; the surface mesh topology is immaterial 
in this context. 

In this example, the floating point values have been truncated for read- 
ability; users are strongly encouraged to provide double-precision values in 
practice. The connectivity information at the end of the hie is not used by 
Fun 3D. It may be omitted if desired; however, it is often instructive to load 
this hie into Tecplot™ for visualization. In that context, the connectivity data 
(including the appropriate J = value in the hie header) will be required. 

For very large surface meshes and/or parameterizations containing a very 
large number of design variables, I/O of this ASCII format can be inefficient. 
There is an alternative C-binary /Fortran stream format that may be used in its 
place; interested users should get in touch with Fun3D-Support@lists . nasa . gov 
for further details on this option. 

To support execution of the user-defined parameterization tool, auxiliary 
hies may be provided in the description.! directory; the filenames should 
be provided in the hie user.def _param_f iles.data (see section 8.6.1). 
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8.4 Design Optimization Directory Structure 

The optimization driver opt_driver requires a very specific directory struc- 
ture. It can be established by running opt .driver in an interactive mode 
with the — setup.design command line option. The number of design points 
should be 1 for single-point design or greater than 1 for multi-point design. 

opt_driver — setup_design [number of design points] 

This interactive command will prompt the user for several directory paths 
required by the optimization, namely the paths to the Fun 3D source code, 
the configuration directory where Fun 3D was configured and built, and the 
path to the location where the design will be performed. Here, directories 
should be provided as absolute paths contained in single quotes, with trailing 
slashes omitted, i.e., 

' /absolute/path ' 

At the completion of this setup procedure, a summary of the files required 
from the user will be echoed to the screen. The directories created in the 
specified run location are shown in Table 11. The i suffix in description.! 


Table 11: Directory structure required for FuN3D-based design. 

Directory Description 

ammo Location where optimization will be executed 

description.! Location of all baseline input files describing design point i 

model. i Location where analysis & sensitivity analysis of design point i will be performed 

and model, i represents the design point index. For single-point design, this 
will be 1; for multi-point design, this value will range from 1 to the number 
of user-specified design points. The setup procedure will populate the various 
directories with links to the required Fun 3D executables and templates for 
various input files described below. 

8.5 Contents of the ammo Directory 

The ammo directory will contain files related to the optimization procedure 
itself. This includes the ammo, input input file and a link to the opt .driver 

executable. 

8.5.1 ammo, input 

The input parameters contained in this file control the actual optimization 
procedure. A template of the file will be installed during the setup procedure; 
an example is also provided below. 
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Optimization package 

4 

Base directory from which to run optimization 
' /home/user/TestAMMO 1 
Number of design points 
2 

Weights for each design point 
1.0 
1.5 

Operation to perform 
1 

Restart the optimization 
0 

Maximum number of flow solves 
10 

Maximum number of design cycles 

5 

Relative convergence criterion for subproblem 
l.e-5 

Absolute feasibility tolerance for constraint violation 

110.0 

Number of bodies with spatial transforms 
2 

List of bodies with spatial transforms 
2 3 

Body grouping desired 
0 

Executable for running MPI programs 
'mpirun' 

Number of processors from which to run adjoint solver 
1024 

DOT method 
0 

User-defined parameterization executable name 
' MyParameterizationExecutable 1 

The various inputs specified in the ammo. input input file are described be- 
low. Care should be taken to preserve the structure of this file when modifying 
its contents. 

Optimization package This scalar integer specifies the optimizer to be 
used. The available choices are (1) DOT/BIGDOT™, (3) KSOPT, (4) PORT, 
(5) NPSOL™, and (6) SNOPT M . Note that the PORT package does not sup- 
port the use of explicit constraints. Also note that Fun3D must be configured 
and built against the selected library. 

Base directory from which to run optimization This should be an 

absolute path to the design location specified during the setup procedure. 
Path should be enclosed in single quotes and contain no trailing slashes. 
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Number of design points This scalar integer is the number of design points 
to be considered during the optimization. The value should be at least 1 and 
less than or equal to the number of design points specified during the setup 
procedure. 

Weights for each design point A non-negative real-valued scalar should 
be specified on separate lines for each design point. The value represents the 
weighting to be applied in the linear combination of objective functions from 
each individual design point as used to construct the final composite objective 
function (see section 8.10). For single point optimization, a single value of 1.0 
should be specified. 

Operation to perform This scalar integer specifies what operation the 
optimization driver should perform. The valid values are (1) Analysis only, 
(2) Analysis and sensitivity analysis, and (3) Optimization. 

Restart the optimization This scalar integer specifies whether to start the 
optimization from the baseline problem description (0), or to restart the opti- 
mization from a previous optimization run already executed in this directory 
( 1 )- 

Maximum number of flow solves This scalar integer is only relevant for 
PORT-based optimizations and sets an upper limit on the number of flow 
solutions allowed during the design. 

Maximum number of design cycles This scalar integer sets an upper 
limit on the number of design cycles the optimizer may perform. 

Relative convergence criterion for subproblem This scalar real value is 
only relevant for DOT /BIGDOT M - and PORT-based optimizations and spec- 
ifies the relative function convergence criterion for which the optimization will 
terminate. 

Absolute feasibility tolerance for constraint violation This scalar real 
value is only relevant for optimizations based on the DOT /BIGDOT M , NPSOL M , 
and SNOPT M packages. The value specifies the feasibility tolerance for con- 
straints. 

Number of bodies with spatial transforms This scalar integer specifies 
the number of MASSOUD-parameterized bodies for which spatial transforms 
should be applied. See also section 8.6.10. 
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List of bodies with spatial transforms This is a list of integers sep- 
arated by spaces specifying the MASSOUD-parameterized bodies to which 
spatial transforms are to be applied. There should be Number of bodies 
with spatial transforms entries in this list. If Number of bodies with 
spatial transforms is zero, this line of data should not be present. See also 
section 8.6.10. 

Body grouping desired This scalar integer specifies whether any body 
grouping should be applied. A value of 0 indicates no grouping should be ap- 
plied; a value of 1 indicates grouping should be applied. See also section 8.6.4. 

Executable for running MPI programs This single character string en- 
closed in single quotes will be used as a prefix when running MPI programs. 

This is usually mpirun or mpiexec, depending on the MPI implementation, or 
perhaps aprun on Cray® systems. 

Number of processors from which to run adjoint solver This scalar 
integer specifies the number of processors on which to execute the adjoint 
solver. Normally this is the same number of processors requested for the job 
and used for the flow solver. However, in the event of a split communicator 
in the flow solver (for Suggar++, Visit, dedicated hie I/O, etc), the adjoint 
solver must be run on the same number of processors that the actual how 
solver was run on (does not include processors set aside for split communicator 
functionalities). 

DOT method This scalar integer is only used for DOT/BIGDOT M -bas e d 
optimization and specihes the optimization method to be used with DOT /BIGDOT M . 
See the DOT /BIGDOT M documentation for further information. 

User-defined parameterization executable name This string should be 
enclosed in single quotes and represents the name of the executable (or script) 
to be launched if user-defined geometric parameterizations are to be used. The 
executable should be available in the users PATH. See also section 8.3.4. 

8.6 Contents of the description.! Directory 

The description.! directory serves as a repository for the baseline hies for 
the CFD model, the geometric parameterization, and several other input hies 
related to the computational model for the ith design point. These hies must 
be set up by the user prior to the run and will not be modified by Fun 3D dur- 
ing execution. During the initial setup procedure, templates for several input 
hies will be placed in this location to aid in setting up the case. During the 
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actual optimization, the optimization driver will copy files from this directory 
into the model . i directory as needed. 

Any hies normally required by the how solver must be present in this 
directory. This would typically include the grid and boundary condition hies 
and fun3d.nml. If the mesh uses overset grids assembled with the Suggar++ 
utility, the Suggar++ DCI hie must be present as well. The optional hie 
remove_boundaries_from_f orce_totals (section B.3) may also be present, if 
desired. 

In addition to the hies normally required by the how solver, a number of 
other hies must also be present to perform the design optimization, some of 
which are optional. These are described below. 

8.6.1 Geometry Parameterization Files 

If performing shape optimization, the user must provide the relevant parame- 
terization hies for each body in the mesh to be modified. The specihc set of 
hies required for each body depends on the parameterization package(s) being 
used. 


MASSOUD Parameterizations For MASSOUD parameterizations, the 
MASSOUD parameterization hies should be named design. gp.j, where j is 
the index of the body to be designed. The hies specifying the values of the 
raw MASSOUD variables should be named design, j for each of the bodies 
to be designed. For FuN3D-based design, the custom design variable linking 
feature of MASSOUD must be used. If the raw MASSOUD variables are 
intended to be used as-is, simply set the linking matrix as the identity matrix 
in the MASSOUD .usd hie. These hies specifying the design variable linking 
for each body should be named design. usd. j . 

The MASSOUD control hie specihes the names of the hies outlined above 
for MASSOUD and must be provided as massoud.j for the jth body. The 
hies listed in the MASSOUD control hie must rehect these names. The hrst 
line of the MASSOUD control hle(s) must have a positive integer equal to 
the number of custom design variables. If the intent is simply to use the raw 
MASSOUD variables as-is, this value is simply the number of raw MASSOUD 
variables for that body. For the in/out-of-core parameter, use in-core (0). 
The hie name for Tecplot™ output viewing must be named model. tec. j for 
the jth body. The design variable grouping hie specihed should be named 
designVariableGroups. j for the jth body. The FAST output hie name can be 
named anything the user wishes; the Fun3D tools do not use this MASSOUD 
output hie. Finally, the user design variable hie for the jth body should be 
named customDV.j. In summary, a massoud.j control hie for the jth body 
should look like the following: 
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#MASSOUD INPUT FILE 

# runOption O-analysis, >0-sd users dvs, -1-sd massouds dvs 
52 

# core 0-incore solution, 1-out of core solution 
0 

# input parameterized file 
design. gp. 1 

# design variable input file 
design. 1 

# input sensitivity file - used for runOption > 0 
design. usd. 1 

# output file grid file 
newf rame .fast . 1 

# output Tecplot file for viewing 
model . tec . 1 

# file containing the design variables group 
designVariableGroups . 1 

# user design variable file 
customDV . 1 

Bandaid Parameterizations For Bandaid parameterizations, the input 
files created by the Bandaid setup tool should be named bandaid. data. j for 
the jth body. Because Bandaid parameters behave linearly, the sensitivities 
contained in these hies are constant and this input is all that is required during 
the course of a design. 

Sculptor™ Parameterizations For Sculptor M parameterizations, the user 

must provide [project_rootname] .mdf , [project_rootname] .sdl, [project_rootname] 

.vol, and [project_rootname] .stu hies. See the Sculptor M documentation 

for more details on each of these hies. A hie named [project_rootname] .def 

must also be provided. An example [projectxrootname] .def hie for a simple 

two-body parameterization is shown below: 

set_mdf [project_rootname] .mdf 
default 1 DV1-T1 0.00 
default 1 DV1-T2 0.00 
default 1 DV1-T3 0.00 
default 1 DV1-T4 0.00 
default 1 DV1-T5 0.00 
default 2 DV2-T1 0.00 
default 2 DV2-T2 0.00 
default 2 DV2-T3 0.00 
export model. tec. 1 
exit 


64 



The filename specified for the export command must be raodel.tec.l. The 
remainder of the file is dictated by the specific parameterization developed in 
the Sculptor M application. 

After the configuration has been parameterized using Sculptor 11 and all of 
the appropriate files have been assembled for FuN3D-based design, a copy 
of the original [project_rootname] _raassoud_bndry#.dat file must also be 
placed in the description.! directory, but with the file name changed to 
[project_rootname] .sdl. Sculptor M requires this baseline file during the op- 
timization. 

Finally, prior to performing the design, the [project_rootname] .sdl file 
must be read into Sculptor M in GUI mode as “Import Mesh/CFD as Tec- 
plot Point FE.” Following this, the Sculptor volumes need to be imported 
onto the [projectxrootname] .sdl file, and then the model must be saved 
again. Once this is done, the command export raodel.tec.l within the 
[project_rootname] .def batch script will generate a model.tec.l.sdl file as 
needed for FuN3D-based design optimization. 

User-Defined Parameterizations In the event that a user-defined geo- 
metric parameterization package is to be used, the user must provide a file 
user.def _param_f iles.data. Since Fun3D will not be aware of any auxiliary 
files that may be needed by the user-defined parameterization package, those 
files should be listed here, with a single file name per line. Each file named 
here must be provided by the user. At run time, Fun3D will move the named 
files to the appropriate location prior to execution of the parameterization 
executable indicated by the user in ammo. input. See also section 8.3.4 and 
section 8.5.1. 

8.6.2 rubber, data 

This section describes how to set up each block of the design control file 
rubber. data. The template provided in the Adjoint directory of the source 
code distribution is installed in the description. i directory during setup. 
This file serves as the primary control file during the course of the optimiza- 
tion and stores all of the high-level information relevant to the design. The file 
is repeatedly read and updated by the various tools during the design proce- 
dure. A simple example of this file to be used for discussion purposes is shown 
below. 

################################################################################ 
########################### Design Variable Information ######################## 
################################################################################ 

Global design variables (Mach number, AOA, Yaw, Noninertial rates) 

Var Active Value Lower Bound Upper Bound 

Mach 0 0 . 800000000000000E+00 0 . 000000000000000E+00 0 . 900000000000000E+00 

AOA 1 1.000000000000000E+00 0 . 000000000000000E+00 5 . 000000000000000E+00 

Yaw 0 0.000000000000000E+00 0 . 000000000000000E+00 0 . 000000000000000E+00 
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xrate 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

yrate 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

zrate 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

Number of bodies 
2 

Rigid motion design variables for 'wing' 

Var Active Value Lower Bound Upper Bound 

RotRate 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotFreq 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotAmpl 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotOrgx 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotOrgy 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotOrgz 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotVecx 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotVecy 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotVecz 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnRate 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnFreq 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnAmpl 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecx 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecy 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecz 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

Parameterization Scheme (Massoud=l Bandaids=2 Sculptor=4 User-Def ined=5) 

1 

Number of shape variables for 'wing' 

3 

Index Active Value Lower Bound Upper Bound 

1 1 1. OOOOOOOOOOOOOOOE+OO 0. OOOOOOOOOOOOOOOE+OO 2. OOOOOOOOOOOOOOOE+OO 

2 1 1. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 2. OOOOOOOOOOOOOOOE+OO 

3 1 1. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 2. OOOOOOOOOOOOOOOE+OO 

Rigid motion design variables for 'tail' 

Var Active Value Lower Bound Upper Bound 

RotRate 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotFreq 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotAmpl 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotOrgx 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotOrgy 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotOrgz 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotVecx 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotVecy 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

RotVecz 0 0. OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnRate 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnFreq 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnAmpl 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecx 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecy 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecz 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

Parameterization Scheme (Massoud=l Bandaids=2 Sculptor=4 User-Def ined=5) 

2 

Number of shape variables for 'tail' 

2 

Index Active Value Lower Bound Upper Bound 

1 1 2. OOOOOOOOOOOOOOOE+OO -1 . OOOOOOOOOOOOOOOE+OO 5. OOOOOOOOOOOOOOOE+OO 

2 1 2. OOOOOOOOOOOOOOOE+OO -1 . OOOOOOOOOOOOOOOE+OO 5 . OOOOOOOOOOOOOOOE+OO 

################################################################################ 
############################### Function Information ########################### 
################################################################################ 
Number of composite functions for design problem statement 

2 

################################################################################ 
Cost function (1) or constraint (2) 

1 

If constraint , lower and upper bounds 
0.0 0.0 

Number of components for function 1 
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1 

Physical timestep interval where function is defined 
1 1 

Composite function weight, target, and power 

1.0 0.0 1.0 

Components of function 1: boundary id (O=all)/name/value/weight/target/power 

0 cl 0.000000000000000 1.000 10.00000 2.000 

Current value of function 1 

0.000000000000000 

Current derivatives of function wrt global design variables 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 2 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 2 
0.000000000000000 
0.000000000000000 

################################################################################ 
Cost function (1) or constraint (2) 

2 

If constraint , lower and upper bounds 
-0.03 -0.01 

Number of components for function 2 

1 

Physical timestep interval where function is defined 
1 1 

Composite function weight, target, and power 
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1.0 0.0 1.0 

Components of function 2: boundary id (O=all)/name/value/weight/target/power 
0 cmy 0.000000000000000 1.000 0.00000 1.000 

Current value of function 2 
0.000000000000000 

Current derivatives of function wrt global design variables 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 2 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 2 
0.000000000000000 
0.000000000000000 


Global Design Variable Data This section of rubber. data lays out global 
design variables for the computation. These include the freestream Mach num- 
ber, angle of attack, and angle of yaw. For simulations using a noninertial ref- 
erence frame, the noninertial rotation rates about each of the three Cartesian 
coordinate axes are also available as design variables. 

Quantities associated with each variable are specified on their own row 
in the hie and have several attributes that must be set by the user. The first 
column is a dummy index and is merely to assist the user in quickly navigating 



through the hie. The second column is a toggle to activate the design variable. 
If this value is a 1, the variable will be allowed to change during the design. 
If the value is assigned a 0, this variable will be held constant at the value 
specified. For incompressible hows and mixed-element grids, the Mach number 
must be declared inactive. Similarly, for hows posed in the inertial reference 
frame, the noninertial rates must be declared inactive. 

The third column in the design variable block is the current value for 
this design variable. The values of any active variables in this hie will take 
precedence over other input decks during design. For example, the how solver 
will run an angle of attack of 1 degree in this case, regardless of what may be 
specihed in fun3d.nml. Columns four and hve specify the upper and lower 
bounds for the current design variable. 

Body-Specific Design Variable Data The next input following the Mach 
number and angle of attack entries specifies the number of bodies for which 
the user has provided shape par ameterizat ions. Note that not every body in 
the grid must be included here. If the wing of an aircraft is the sole focus of 
the optimization, there is no need to account for other boundaries such as the 
tail or fuselage here. 

Following the number of bodies, there should be two blocks of design vari- 
ables for each desired body, namely a list of rigid motion variables controlling 
the dynamics of the body, and a set of shape parameters controlling the shape 
of the body. The columns of inputs are identical to those described above for 
Mach number and angle of attack. 

The bodies present in the computation may be listed in any order; how- 
ever, the order of their appearance in this control file must match the integer 
suffix on their parameterization files that are provided in the description.! 
directory, as well as files such as body .grouping. data, transf orms.j, etc. 

The first section for the current body specifies design variables governing 
rigid body motion and is only applicable for time-dependent problems. For 
optimization of steady flows and/or static geometries, the rigid motion data 
is irrelevant but must be present in this file. These variables should be set as 
inactive in these cases. 

The next block of inputs relates to the shape parameterization for the 
current body. First, the parameterization scheme is identified by a scalar 
integer. The following values are available: (1) MASSOUD, (2) Bandaids, 
(4) Sculptor M , and (5) User-Defined. The next input specifies the number of 
parameterized shape variables on the current body and the subsequent lines 
lay out the design variable information for that body. A row of data must 
be provided for every variable in the parameterization, whether it is active 
or not. (Note however, that internally, the optimizer is only made aware of 
the variables marked as active.) If a parameterization contains 25 variables, 
then 25 rows must appear in this corresponding block of rubber. data, even if 
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only a subset is active. If the design variable linking feature in MASSOUD or 
Bandaids has been used to create additional derived variables, they must also 
appear here. Note that the “Active” attribute for shape variables may take 
values of not only 0 or 1, but also —1 in certain multi-point design scenarios 
(see section 8.10). 

Care should be taken in choosing upper and lower bounds for shape vari- 
ables. Optimizers tend to fully explore the design space, which may result in 
infeasible shapes (or extreme shapes the mesh movement /solvers cannot han- 
dle robustly). Set these limits conservatively; one can always restart a design 
with less restrictive bounds. 

As noted previously, when using Sculptor M parameterizations for multiple 
bodies, all such design variables must appear as a single concatenated body in 

rubber . data. 


Cost Function/Constraint Specification The first line following the de- 
sign variable block specifies the total number of composite functions to be used 
as objectives or constraints for the current design point. Multiple composite 
objective functions may be specified in certain cases; see section 8.9. Other- 
wise, a single composite objective function must be specified. The example 
file shown here contains a single composite objective function based on the 
lift coefficient and a single explicit constraint based on the pitching moment. 
Note that explicit constraints may only be specified if the optimization package 
chosen in ammo . input supports them. 

Following the scalar value specifying the total number of composite objec- 
tives and constraints, each composite function and/or constraint will have a 
block of data associated with it. Objective functions and constraints may be 
specified in any order. 

The first two inputs in the composite function block specify a scalar integer 
indicating how the current function is to be viewed by the optimizer. The two 
subsequent inputs represent lower and upper bounds on the function if it is 
to be used as a constraint. If the function is an objective function, the first 
input value should be 1, and the lower and upper bounds must be present but 
their values are irrelevant. However, if the current function is to be used as 
a constraint, special attention must be paid to these inputs depending on the 
optimization package being used. 


Constraints Using NPSOL™ and SNOPT™ If the current function 
is to be used as an inequality constraint, the first input should be 2, and 
the lower and upper bounds should be set to their appropriate values. If the 
current function is to be used as an equality constraint, the first input should 
be 2; however, the lower and upper bounds should both be set equal to the 
desired constraint value. 
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Constraints Using KSOPT and DOT/BIGDOT™ These optimiza- 
tion packages assume constraint functions of the form / < 0, such that the 
bound of the feasibility region is implicit in the function definition and the 
lower and upper bound inputs must be present but are not used. If the cur- 
rent function is intended as an inequality constraint, the first input should be 
2. If the current function is intended as an equality constraint, the first input 
value should be 3. In this case, Fun3D’s design driver will provide the current 
function to the optimizer as an inequality constraint, but will also bookkeep 
an equal and opposite function as an additional inequality constraint. In this 
manner, an equality constraint is achieved by only allowing the intersection of 
the two inequality constraints as feasible. 

Following the classification of the current function, the next line states how 
many component functions comprise the current composite function. This can 
be any positive integer greater than or equal to 1. Following the number of 
component functions, the user must specify the physical time step interval over 
which the function is to be applied. This input is only relevant to optimization 
of unsteady flows. For steady flows, the values of these two inputs are ignored 
but must be present. 

The weight, target, and power to be applied to the current composite 
function are specified next. These values are only relevant when combining 
multiple composite objective functions into a single global objective function 
(see section 8.9). For all other cases, these values should be specified as 1.0, 
0.0, and 1.0, respectively. 

At this point, each component function that contributes to the current 
composite function has a line specifying several pieces of data. The first col- 
umn is the boundary patch over which to apply the current component. This 
index corresponds directly to the boundary patches in the CFD grid, and 
must reflect any patch lumping that is indicated in the &raw_grid namelist 
in fun3d.nral (see section B.4.2). If a component function is to be used over 
the entire grid (total drag, for example), simply put a 0 in this column. Al- 
ternatively, if a single boundary patch is to be targeted, one might apply the 
component function to only that patch. Several patches may be targeted by 
including a component function for each. The next column is the keyword for 
the aerodynamic quantity to be used for the current function component. For 
a list of available keywords, see section 8.1. The next column contains the cur- 
rent value of the current function component. This is an output value during 
the optimization and need not be set by the user. The final three columns in 
the row correspond to the weight, target value, and power to be applied to the 
current component function in constructing the overall composite function. 

Current Function Value and Sensitivities Following the specification of 
the component functions, the next line of rubber. data contains the current 
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value of the composite function. This is an output and need not be set by the 
user. 

The remaining lines in the current function block contain the sensitivity 
derivatives with respect to all of the design variables listed in the top half of the 
hie. This section is divided into derivatives with respect to the global design 
variables, as well as the rigid motion and shape design variables for each of the 
bodies laid out in the top portion of the hie. These derivatives are outputs set 
by Fun3D and not by the user. However, a line for each design variable (both 
global variables as well as body-specihc variables) must be provided in each 
composite function block present. The values do not matter, but the solvers 
need positions available in the hie to store the current values. 


8.6.3 ae target.dat (optional) 

If the function keyword ae is specihed anywhere in rubber. data, the hie 
ae_target.dat must be present prior to performing the optimization. This hie 
provides the target equivalent area distribution(s) for each of the azimuthal 
locations specihed in the &equivalent_area namelist in fun3d.nml (in the 
same order). See section 8.2.8 and section B.4.35. 


8.6.4 body .grouping, data (optional) 

This hie is used to specify body grouping information. For example, if the 
objective function is the Figure of Merit FM for a three-bladed rotor, then 
the three blades (each typically specihed as a separate parameterized body in 
rubber. data) should be associated into one group, so that sensitivity deriva- 
tives will rehect a composite d(FM)/dD for all three blades. This capability 
requires that the bodies to be associated all have identical parameterizations 
(same number of design variables on each body, etc). The format of the 
body .grouping. data hie is as follows: 


Number of groups to create 
1 

Number of bodies in group, list of bodies 
3 

1 2 3 


The hrst scalar integer specihes the number of groups to create (i.e. , one rotor). 
The next set of inputs specihes the number of bodies in each group, followed 
by the bodies that comprise that group (i.e., each of the three rotor blade 
bodies). 
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8.6.5 command line . options (optional) 

The command_line . options file specifies any command line options to be used 
with the flow solver, the adjoint solver, or the MPI job launcher (mpirun, 
mpiexec, aprun, etc). An example of this file is shown below. 

3 

1 flow 

' — rmstol l.e-7' 

1 adjoint 

' — rmstol l.e-3 1 

2 mpirun 

' -nolocal ' 

' -machinef ile . . /machinef ile ' 

The first line of the file specifies the number of programs for which command 
line options are being provided. The subsequent line must contain an integer 
followed by a keyword. The integer specifies how many command line options 
are being provided for the code identified by the keyword. The valid keywords 
are flow, adjoint, and mpirun. This line is followed by a line for each of the 
command line options provided for the code identified by the keyword. Each 
command line option should appear in single quotation marks on its own line. 
The specified programs and their associated command line options may appear 
in any order. 

8.6.6 cpstar.data. j (optional) 

Fun3D has an inverse design capability where the objective function may 
be composed of target pressure distributions. The file containing the jth 
target distribution must be named cpstar.data.j. However, setup is te- 
dious, primarily due to the difficulty in specifying pressure distributions on 
a three-dimensional configuration. If this capability is of interest, please con- 
tact Fun3D-Support@lists.nasa.gov for more detailed guidance. 

8.6.7 f iles_to_save .data (optional) 

If desired, users may indicate specific hies produced by the how and adjoint 
solvers to be archived during an optimization. For example, custom visual- 
ization hies may be produced at each design iteration (see section 5.3.1) to 
enable animations of the design history after the optimization is complete. 

To specify certain hies to be archived during the course of a design ex- 
ecution, the user may provide the optional hie f iles_to_save.data in the 
description.! directory. Each line of the hie consists of one of two key- 
words, either “Flow” or “Adjoint”, followed by the specihc name of a hie to 
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be archived. For example, the following inputs could be used to archive Tec- 
plot™ hies containing solution data on boundaries for both the how and adjoint 
solvers, while also saving two additional Tecplot™ hies containing user-specihed 
sampling data for the how solution: 

Flow [pro j ect_rootname] _tec_boundary . dat 
Flow [pro j ect_rootname] _tec_sampling_geoml . dat 
Flow [pro j ect_rootname] _tec_sampling_geom2 . dat 
Adjoint [pro j ect_rootname] _tec_boundary . dat 

At the end of each function evaluation (i.e., how solution) for the ith design 
point, the hies [project_rootnamej_tec_boundary.dat, [project_rootname] 
_tec_sampling_geoml.dat, and [pro j ect_rootname] _tec_sampling_geom2.dat 
will be stored in the model. i/Flow/SaveFiles directory, with an integer cor- 
responding to the current design iteration appended to each of the filenames. 
Similarly, the hie [projectvrootname] _tec_boundary.dat will be stored in the 
model. i/Adjoint/SaveFiles directory at the completion of each sensitivity 
analysis (i.e., adjoint solution). 

8.6.8 machinefile (optional) 

If the optimization will be executed in an environment which requires an ex- 
plicit list of machines on which the MPI jobs will be executed, this hie must 
be present. It should take the format required of the particular MPI imple- 
mentation being used. If the optimization will be executed in an automated 
queuing environment, the job scheduler normally assigns the machines to be 
used at runtime and this hie is therefore not required. 

8.6.9 pressure_target.dat (optional) 

If the function keyword boomvtarg is specihed anywhere in rubber. data, the 
hie pressure_target.dat must be present prior to performing the optimiza- 
tion. This hie provides the nearheld target p/p <*, distribution(s) for each of 
the off-body locations specihed in the &sonic_boom namelist in fun3d.nml (in 
the same order). See section 8.2.6 and section B.4.33. 

8.6.10 transforms.! (optional) 

Since MASSOUD uses a coordinate system specihc to an assumed aircraft 
orientation, it is sometimes necessary to reorient a body from its physical 
position to a MASSOUD-aligned coordinate system and vice-versa. Examples 
might include a vertical tail or the various blades of a rotor system. The hie 
describing the transform for the ith body should be included as transforms.!. 
The format of a typical transforms.! hie is as follows: 
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ROTATE 0.0 0.0 1.0 -120.0 


This would rotate the MASSOUD parameterization for the ith body by —120 
degrees about a unit vector in the +z direction. The commands TRANSLATE 
and SCALE are also available. 

8.7 Contents of the model, i Directory 

Just as for the description.! directories, the i in the model . i naming con- 
vention represents the design point index. This value is 1 for single point design 
or the design point index for multi-point design. The model . i directory con- 
tains the subdirectories Flow, Adjoint, and Rubberize. During the course 
of the design procedure, Fun3D will evaluate the relevant parameterizations 
and perform flow and adjoint solutions within these locations. These sub- 
directories are populated during the initial setup procedure with links to the 
required executables from the user’s Fun3D installation. Files in the model . i 
subdirectories should not be modified by the user, although one may wish to 
observe various solver output hies during the course of the optimization. All 
user-provided inputs are confined to hies located in the description.! and 
ammo directories. 

8.8 Running the Optimization 

Once all of the required inputs and hies have been provided, the user should 
hrst request a single function evaluation from the optimization driver. This is 
strongly recommended in order to identify any potential issues in the various 
inputs. To perform this check, set the value of Operation to perform in 
ammo . input to 1, and execute the optimization driver from the ammo subdi- 
rectory: 

opt_driver > screen. output & 

Here, the output from the optimization driver has been redirected to a hie 
called screen, output. This hie is very useful if a problem needs to be diag- 
nosed with the execution. It is also good practice to include this hie with help 
requests to Fun3D-Support@lists.nasa.gov. 

At the completion of the function evaluation, the user should check for the 
desired/expected result. This is also a good opportunity to establish reason- 
able values for the number of time steps to run, the residual tolerance at which 
the solver should quit, and so forth. Such run control parameters may be set 
in fun3d.nml or via the commandAine . options hie. 

Once the function evaluation procedure has been verihed, the user should 
perform the same test for a sensitivity analysis by setting Operation to 
perform in ammo . input to 2 and re-executing the optimization driver. Similar 
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checks on convergence parameters, etc for the adjoint solver should be noted 
and applied to the relevant input hies. 

With successful function and gradient evaluations in hand, an actual opti- 
mization may be initiated. The value of Operation to perform in ammo . input 
should be set to 3, and the optimization driver can be executed as before. The 
user should closely monitor the screen output as the process proceeds, espe- 
cially during the first several design cycles when input parameters may first 
cause problems. The largest changes in design variables often occur early on 
as well, which can cause issues with mesh movement operations, solver con- 
vergence, and other aspects, ft is also very useful to occasionally filter the 
screen output for the current function value (s) reported at the completion of 
each how solution in order to monitor overall progress: 

grep "Current value of function" screen . output 

When an optimization completes, the optimizer will report the reason for 
the termination to the screen, which may be a local minimum, or some prob- 
lem encountered during the simulation. A summary of the optimization is 
provided by each optimization package in the hle(s) noted in Table 12. The 
hnal set of design variables and function/constraint values determined by the 
optimizer will be available in model, i/rubber. data. To track the history of the 
optimization, a backup of all intermediate copies of rubber. data are stored 
in the directory model. i/Rubberize/surf ace_history. Intermediate copies 
of the surface grids developed during the design process are also stored in this 
location as model. tec. j.sdl. iter, where j is the body index, and iter is the 
design iteration. These hies may be used to produce animations of the surface 
history if desired. Using the broad range of visualization output options for 
the solvers, the user has great freedom to produce customized animations of 
the design history (see section 8.6.7). 

Table 12: Files containing design summary from various optimization packages. 


8.8.1 Filesystem Latency Problems 

Design optimization using some cached hie systems may experience problems 
due to the rapid execution of the various tools during the design process. In 
some cases, a hie system lag may cause some processes to receive older/stale 


Optimization Package Summary File(s) 


DOT/BIGDOT™ 

KSOPT 

PORT 

NPSOL™ 

SNOPT™ 


dot. output 
ksopt. output 
port. output 

npsol.printfile, npsol.summaryfile 
snopt.printfile, snopt.su mmaryfile 
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versions of files during execution. Specifying the — sleep_delay [seconds] 
command line option to the opt_driver executable will pause the optimization 
process with a sleep duration of seconds between subsequent code executions 
to allow the hie system to perform correctly. On older systems, delays as large 
as 60 seconds are sometimes necessary; more recent systems seem to perform 
considerably better and values of 5-10 seconds are often sufficient. 

8.9 Multi-objective Design 

KSOPT, PORT, and SNOPT M are the only packages currently supported for 
use with multi-objective design. Details on the usage for each package are 
provided below. 

8.9.1 KSOPT 

KSOPT is the only supported optimization package with explicit support for 
multiple objective functions. When using KSOPT, the user may designate any 
number of composite functions as objective functions in rubber. data. 

8.9.2 PORT, SNOPT™ 

The Fun3D design driver offers a simple approach to scalarizing multiple user- 
specified objective functions for use with the PORT or SNOPT M packages. If 
multiple composite functions are specified in rubber. data, the Fun3D design 
driver will combine them using the weight, target, and power values specified 
at the composite function level (i.e. , the input values that appear just before 
the component function data is specified in rubber. data, see section 8.6.2). If 
N composite functions / are labeled as objective functions in rubber. data, the 
scalarized objective function F to be provided to the optimization procedure 
will take the form 

f = «!(/! - nr + « 2 (/ 2 - nr + ... + <* N (f N - r N y N ( 12 ) 

where cq, f * , and pi are the weight, target, and power values associated with 
each composite function in rubber. data. 

8.10 Multi-point Design 

The Fun 3D design infrastructure offers several approaches to multi-point op- 
timization. This refers to design problems where the user may wish to simul- 
taneously optimize a configuration for operations at two different conditions 
- perhaps the beginning and end of a cruise segment for example, where the 
aircraft weight may be substantially different. The user may also wish to de- 
sign for cruise and takeoff or landing (or all three). The various design points 
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may be characterized by different flow conditions (i.e., speed, angle of attack, 
etc), or more generally, by the geometries (and therefore grids) at each point. 
For example, one design point may consist of a cruise geometry operating at 
Mach 0.8, while another design point may be a landing configuration operating 
at Mach 0.2 with a high-lift system deployed. For examples of FuN3D-based 
multi-point design in practice, see the studies in [12] and [20]. In these ref- 
erences, a tilt-rotor geometry has been optimized for a set of several blade 
collective settings as well as hover and forward flight conditions. 

To perform a multi-point optimization, the user must request the desired 
number of design points when setting up the directory structure where the 
design will be performed (see section 8.4). The user must populate each of the 
description.! directories for each design point i just as in the single-point 
design context. The order of the design points does not matter. The value 
of Number of design points in ammo. input should be set appropriately. Ul- 
timately, Fun 3D provides several ways to formulate the multi-point design 
problem. These approaches are outlined below. 

In general, the optimizer will be seeking a unique set of design variables 
to simultaneously achieve goals at all of the design points. For this reason, a 
consistent set of design variables across all design points must be used. This 
applies to the global variables Mach number and angle of attack as well as any 
body-specific variables such as shape parameters. For example, if a set of 15 
thickness variables is provided for a wing shape in cruise, other design points 
(again, perhaps a landing configuration as an example) must utilize the same 
set of 15 thickness variables. Moreover, the same subset of design variables 
must be active at each design point. 

Multi-valued Design Variables In some situations, the user may desire 
different optimal values of a design variable at different design points. For 
example, consider power minimization for a rotor in hover at two different 
weight conditions, where each of the two design points may have different 
minimum thrust coefficients posed as constraints. In addition to other design 
variables that may be present, the user may have a shape parameter controlling 
the blade collective setting (blade pitch). However, rather than constraining 
the optimal blade collective to a single unique value, the user may desire 
separate, optimal values for each design point. As another example, consider 
a configuration with an ability to actively morph its outer mold line. In this 
case, the user may wish to determine optimal values of the shape parameters 
that are unique to different design points. 

To accommodate such multi-valued design variables, the user may set the 
“Active” attribute for individual shape design variables to —1 in rubber. data 
(see section 8.6.2). If this is done, it must be applied consistently for that 
same variable across all design points. For variables with this attribute, the 
Fun 3D design driver will internally bookkeep separate values of the variable 
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for each design point. This feature is currently only available for use with the 
SNOPT™ package. 

8.10.1 Linear Combination of Objective Functions 

The most straightforward approach to multi-point design is to linearly combine 
individual objective functions /* from each of the N design points i into a single 
global objective function f mp : 

fmp — Qp/i + 012/2 + <^3/3 + + czn/n (13) 

To perform the optimization in this fashion, a single composite objective func- 
tion should be posed in each description. i/rubber. data hie. Each of the a* 
weighting coefficients must be specified as Weights for each design point 
in ammo. input, in the corresponding order. 

This form of multi-point design is supported by PORT, DOT/BIGDOT M , 
and SNOPT M . Note that PORT and SNOPT M will also combine multiple 
objective functions within each design point as described in section 8.9 if de- 
sired. Explicit constraints can be posed at each design point when using 
DOT/BIGDOT M or SNOPT M ; such constraints are each treated individually. 

8.10.2 Combination of Objective Functions using the Kreisselmeier- 
Steinhauser Function 

Another alternative for performing multi-point design is the approach inher- 
ent in the KSOPT package. In this approach, all objective functions and 
constraints are combined using the Kreisselmeier-Steinhauser (KS) function. 
The user is referred to [21] for the details of this formulation. Here, the Fun3D 
design driver gathers any number of objective and constraint functions across 
all design points and provides them to KSOPT, which internally constructs 
its KS function for the actual optimization problem. 

8.10.3 Single-Point Objective Function with Off-Design Constraint 
Functions 

In this approach to multi-point design, a single objective function is provided 
to the optimizer, while all other functions are treated as explicit constraints. 
Here, the user should designate a single composite function across all of the 
description. i/rubber. data input hies as an objective function. Any other 
composite functions at each design point should be designated as constraint 
functions. KSOPT, SNOPT™, and NPSOL M support this form of multi-point 
optimization; SNOPT M can also construct the final objective function by lin- 
early combining multiple objective functions within the desired design point 
as described in section 8.9. 
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8.11 Optimization of Two-Dimensional Geometries 

While the Fun 3D flow solver supports a 2D mode of operation, this capability 
is not currently available from within the design infrastructure. Instead, the 
optimization must be performed as a pseudo-3D case. The user should pro- 
vide a nominally two-dimensional grid, with a single layer of elements in the 
spanwise (y) direction. The mesh should consist of either prisms or hexahedra 
(or both), but should contain no pyramids or tetrahedra. Follow the same 
procedure used for 3D cases to extract the surface grid for parameterization. 
The surface should be parameterized just as for a 3D simulation; however, the 
parameterization should allow no spanwise asymmetries in the geometry to 
develop. When using MASSOUD or Bandaids, this is readily accomplished 
by linking the raw parameters with an equal weighting across the span into a 
single set of design variables that operate in a chordwise fashion. Note that 
the sidewalls should use symmetry _y boundary conditions so that only in-plane 
mesh deformation occurs during the optimization. The design may now be ex- 
ecuted as usual, with the 2D nature of the problem enforced implicitly through 
the parameterization. 

8.12 Using a Different Optimization Package 

In a CFD-based design context, the term “function” implies an evaluation of 
the geometric parameterization, mesh movement (both surface and volume), 
a flow solution, and an evaluation of the output function/constraint for a 
given set of design variables. The file manipulations and solver operations 
necessary to achieve this are not trivial. For users interested in using the 
tools as “black boxes” providing function data for an optimization package, a 
wrapper has been provided in the LibF90 directory of the distribution named 
analysis.f 90. This module contains a subroutine called perf orm_analysis () 
which performs the extensive set of tasks involved with producing the final 
desired function output. 

To obtain sensitivities, the Fun 3D package relies on a discrete adjoint for- 
mulation. As with function evaluations, the low-level operations required to 
perform an adjoint-based sensitivity analysis are numerous. A wrapper routine 
called perf orm_sensitivity_analysis () in the LibF90/sensitivity.f90 
module will perform an adjoint solution for the flow field, an adjoint solu- 
tion for the mesh movement scheme, an evaluation of the linearized geometric 
parameterization, and finally produce the desired sensitivity derivatives. 

The Fun 3D design driver uses the wrappers perf orm_analysis () and 
perf orm_sensitivity_analysis () to greatly simplify function and gradient 
evaluations when connecting to off-the-shelf optimization packages. If the 
user wishes to implement a new optimization strategy, it is highly recom- 
mended that these wrappers be used in a similar fashion. A review of the 
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existing modules in the Design directory of the Fun 3D source code distribu- 
tion, which implement the currently available optimization interfaces, is also 
strongly suggested. Users may contact Fun3D-Support@lists.nasa.gov for 
further guidance in leveraging Fun3D’s capabilities from within their own 
existing design framework. 

8.13 Implementing New Cost Functions/Constraints 

Implementation of new cost functions or constraints is not a trivial undertak- 
ing and requires extensive modification of Fun 3D source code. Experience 
in Fortran 2003, unstructured-grid discretizations, development in a domain- 
decomposed/distributed-memory environment, and general CFD methods are 
essential. Routines to evaluate the proposed function and linearizations of the 
function with respect to both the flow held variables and grid are ultimately 
required. The comp lex- variable form of Fun 3D (see section 8.14) is invalu- 
able in verifying the accuracy of these linearizations. It is highly recommended 
that the user contact Fun3D-Support@lists.nasa.gov for guidance prior to 
attempting the implementation of a new cost function or constraint. 

8.14 Forward Mode Differentiation Using Complex 
Variables 

The reverse, or adjoint, mode of differentiation is primarily used for design 
with Fun 3D. A forward mode of differentiation is also provided based on the 
use of complex variables [22-24], This capability is useful for design problems 
containing few design variables and many cost functions or constraints. To 
generate and build a complex-variable Fun 3D executable, see section A. 5. 

The complex- valued how solver reads the usual real- valued grid hies and is 
set up to compute derivatives of every output variable with respect to Mach 
number, angle of attack, shape parameters, non-inertial rotation rates, or the 
x, y, or z coordinate of a single grid point (others are trivial to add). This 
choice is controlled by the hie perturb. input. A template for this hie is 
provided in the FUN3D_90 directory and an example is also shown below. 

PERTURB EPSILON GRIDPOINT 

2 l.e-50 666 

0 = No perturbation 

1 = Mach number 

2 = Alpha 

3 = Shape 

4 = x-rotation rate 

5 = y-rotation rate 

6 = z-rotation rate 
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7 = Grid point x 

8 = Grid point y 

9 = Grid point z 

10 = Yaw 

100+ = add an imaginary source term to equation 
PERTURB- 100 of node GRIDP0INT 
(to verify the adjoint lambda value) 


The value of PERTURB specifies the variable for which sensitivities will be 
taken with respect to. The valid integer values are as shown above. The input 
EPSILON specifies the magnitude of the imaginary perturbation to be applied. 
The recommended value is l.e-50. If the value of PERTURB is greater than 
six, the value of GRIDP0INT specifies the grid point index to perturb. The 
remaining lines in perturb. input are not read; they are simply reminders of 
the valid inputs just described. The complex- valued flow solver may then be 
executed in a manner similar to the real- valued flow solver: 

mpirun . /complex_nodet_mpi 

To compute derivatives with respect to a shape parameterization variable, the 
sensitivities of the parameterization must first be evaluated in the directory 
model . i/Rubberize using the relevant parameterization software. The value 
of PERTURB should be set to 3 in perturb . input. The complex-valued flow 
solver can then be executed in the following fashion: 

mpirun . /complex_nodet_mpi — dv_index [body] [dv] — snap_grid 

Here, the values of body and dv specify the body and design variable index in 
rubber . data to which to apply the imaginary perturbation. The — snap.grid 
argument forces the flow solver to propagate the surface sensitivities into the 
volume mesh using Fun3D’s elasticity-based deformation mechanics. 

At the completion of the complex-valued flow solve, outputs will contain 
both real and imaginary parts. The imaginary part represents the sensitivity 
of that output with respect to the perturbation variable that was specified in 
perturb . input. 
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Appendix A 


Installation 


Fun3D is distributed as gzipped archive of source code. The GNU build 
system is used to package and install Fun3D. The required installation steps 
are detailed in this section. Due to the large range of capabilities, configuring 
the dependent packages is the most involved step and is the focus this section. 
As was illustrated in the Quick Start section, four basic steps are required: 

1. Extract the source code from the gzipped tarball archive with tar 

2. Configure the desired dependencies and compiler options with conf igure 

3. Compile via make 

4. Install the compiled binaries and supporting scripts via make install 

If any difficulties arise with the installation process please, send the entire 
conf ig. log hie produced by configure and the full stdout and stderr of make 
to Fun3D-Support@lists.nasa.gov. The user is strongly advised against 
editing the configure script or any Makefile it produces. We are unable to 
assist users who have edited these hies. 

A.l Extracting Files 

After downloading the source code as a gzipped tarball, the user can unpack 
it with 

tar zxf fun3d-12 . 5-* . tar .gz 

which will create the directory fun3d-12 . 5-*. (The * represents a code that 
the Fun3D uses internally to version the code.) If you have do not have a 
GNU-compatible tar, you may have to insert a separate decompression step, 
i.e., 


gzip -d fun3d-12 . 5-* . tar .gz | tar zxf - 

A. 2 Configure Introduction 

The Fun 3D suite of tools is configured and built via the GNU build system 
and must be configured hrst. Change to this directory, e.g., cd fun3d-12 . 5-*, 
and execute 

./configure — help 
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to see a list of all available compilation options. When configure is invoked, 
detailed results of all the tests it performs are written to the hie conf ig. log. 
Some features of the configure step that have caused problems for users 

are: 

• An incorrect spelling of a --enable-* or — with-* option is silently 
ignored. This will result in the intended option not being included in 
the compiled executable. 

• Option values containing spaces must be quoted to be correctly inter- 
preted by the shell (i.e. , FCFLAGS=’ -optionl -option2’). 

• If the configure command is executed more than once with different 
options, make clean is required before the make step, so that changes 
to the configuration are correctly reflected in the compiled executable. 

A. 3 Alternative Installation Path 

The path to the installation directory is specified by the — prefix= option. 
The default is to install to /usr/local with executables placed in /usr/ 
local/bin. This default location may not be available if the user does not have 
write permission to this directory (without root or administrator privileges). 

To install to an alternative path (e.g., $H0ME/local), use the — prefix= 
option to set the installation path 

./configure — pref ix=$HOME/local 

Finally, to include the Fun 3D executables in the command search path, add 
setenv PATH $HOME/local/bin: $PATH 
to the ~/.cshrc hie or the equivalent for your shell. 

A. 4 Fortran Compiler Option Tuning (FTune) 

By default, configure will use compiler and linker options chosen by the 
Fun 3D team. The process is referred to as “FTune.” The users PATH is 
searched in a predefined order until the first FuN3D-compatiblc compiler is 
found. When configured with MPI, the build will use mpif90 located in the 
bin directory of the given MPI installation^ 1 However, the user can explicitly 
specify the desired Fortran compiler via the FC environment variable. 

To directly specify the compiler and linker options, use the FCFLAGS and 
LDFLAGS environment variables. The default behavior is to append their values 
to the options defined by FTune. If the — disable-ftune option is given 
to configure, FTune will be disabled and the values given by FCFLAGS and 

A1 To see what the underlying compiler is, use mpif90 -show. 
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LDFLAGS will be used explicitly. For example, to ensure that the Intel® Fortran 
compiler ifort is used with only the -03, -ip, and -Ira options, 

./configure — disable-f tune \ 

FC=ifort \ 

FCFLAGS= ' -03 -ip' \ 

LDFLAGS= ' -lm ' 

The order of variables and options are inconsequential, and single quotation 
marks ( ’ ) are used to protect values with spaces from the shell. Some FTune 
options may be unconditionally required for a given compiler, as in the case of 
linking with the math library -Ira above. 

A. 5 Complex Variable Version 

The Fun 3D suite can be complied with the real variables in the code re- 
placed with complex variables by a source translation tool. This permits 
the computation of forward-mode sensitivities, see section 8.14 for details. 
To enable, add the --enable- complex configure option to the configure 
script. The complex-valued code can be compiled with make complex; and a 
make install will place the complex-valued executables in the bin installa- 
tion directory. Enabling the complex variable version will increase the compile 
time. 

A. 6 Internal Libraries 

Fun 3D has internal dependencies to libraries that are distributed with Fun 3D. 
These libraries are automatically built and linked to Fun 3D by default. 

A. 6.1 KNIFE 

The KNIFE cutcell library provides cutccll capabilities. The --without-knif e 
option will disable this library. 

A. 6. 2 REFINE 

The refine library provides access mesh adaptation and untangling capabil- 
ities. The --without-ref ine option will disable this library. 

A. 7 External Libraries 

Fun 3D relies on external libraries to enable some of its advanced applications. 
Use Table Al to determine which set of external libraries are necessary for your 
applications of interest. Discussions of each external library are found in the 
following sections. 
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Table Al: Configuration options. 


Co 

A? 


.S 


ft 

ft ft 

*o' '0“ ft O v 0 

<$* £ <5 <1 

ft Jft ^ -ft b A £• 

^ ^ A*° o° 

|r Jr A O a c_ <& 

? J? ,8 ,o ? > »o|) . v o 




Option 

<e 

O 

o° 


o° 

•X' 

MPI 

X 






ParMETIS 

X 






SUGGAR 


X 





DiRTlib 

6-DOF 

KSOPT 


X 

X 


X 


PORT 

SNOPT™ 




X 

X 


NPSOL™ 





X 


DOT/BIGDOT™ 





X 


Tec plot™ 






X 

CGNS 







sBOOM 








It is highly recommended that Fun 3D is configured to use a parallel execu- 
tion (MPI and ParMETIS) if you plan to perform any advanced calculations. 
SUGGAR++ and DiRTlib are only required if overset (chimera) meshes will 
be used. The 6-DOF library is only required if six degrees of freedom simu- 
lations will be performed (trajectories determined by integrating the equation 
of motion). KSOPT, PORT, SNOPT™, NPSOL™, and DOT/BIGDOT™ are 
optimization libraries. At least one of these optimization libraries is required 
for performing design optimization. 

A. 7.1 MPI 

MPI provides Fun3D’s capability to communicate between processors. Con- 
figure with the option 

— with-mpi=/path/to/MPI 

where /path/to/MPI is the directory where MPI is installed. 

In addition, Fun 3D must be executed in an environment that repre- 
sents the same MPI installation used for configuration/compilation (e.g. same 
mpiexec, mpirun, etc.). Failure to provide such consistency will result in un- 
defined behavior and undetermined segmentation faults. 

In some cases, MPI may already be installed on the target machine. If it is 
not, OpenMPI or MPICH can be used and the option of static MPI libraries 
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is recommended. Also, if building OpenMPI or MPICH from source, it is 
important to maintain consistency with compilers (both vendor and version) 
throughout the build and execution of Fun3D and its dependent libraries. 

For example, if OpenMPI is built with gfortran version 4.4.7, then the ex- 
ecution environment for Fun3D must reflect the same vendor and version, 
gfortran 4.4.7. Fun3D execution must also employ the same mpiexec from 
the OpenMPI installation used to build the software. 

Some high performance computing environments use a proprietary MPI 
implementation that does not provide mpif90. It that situation, the config- 
ure option — without -mpif 90 may be required in combination with the FC 
environment variable to explicitly set the compiler. 

Verifying the MPI Implementation Functionality A simple Fortran 
program is included in the FUN3D distribution to verify that the MPI imple- 
mentation is functional. This is very helpful for quickly troubleshooting issues 
with the MPI implementation. It is located in utils/MPIcheck. From within 
that directory you should be able to 

mpif 90 -o mpi_hello_world mpi_hello_world.F90 

and execute on two processors 

mpiexec -np 2 . /mpi_hello_world 

0 says, "Hello World!" 5=5 

1 says, "Hello World!" 5=5 

To verify the Fortran compiler that MPI is built with, try 
mpif90 -show 

if the MPI implementation supports it. 

A.7.2 ParMETIS 

Website: http : //glaros. dtc.umn.edu/gkhome/metis/parmetis/overview 

The partitioning library ParMETIS is required for parallel execution. ParMETIS 
is a parallel graph partitioner that is used to perform domain decomposition 
for all parallel Fun3D jobs. It is critical that Fun3D and ParMETIS are 
compiled with exactly the same MPI installation and compilers. This includes 
the C compiler used to compile MPI, ParMETIS, and FUN3D. 

When configuring Fun 3D, use 

— with-parmetis=/path/to/ParMETIS 

where /path/to/ParMETIS is the directory of the ParMETIS installation. 
Fun3D expects the /path/to/ParMETIS directory to contain the following 
hies in lib and install subdirectories, 
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/path/to/ParMETIS/lib/libmetis . a 
/path/to/ParMETIS/lib/libparmetis . a 
/path/to/ParMETIS/ include/metis .h 
/path/to/ParMETIS/ include/parmetis . h 

See the Install.txt instructions in the ParMETIS distribution for build 
instructions. Fun3D requires both libmetis.a and libparmetis.a libraries 
and their accompanying header hies. There is an example of commands to 
build both libraries, 

cd parmetis-4.* 

make config pref ix=/path/to/ParMETIS 
make install 
cd metis 

make config pref ix=/path/to/ParMETIS 
make install 

where /path/to/ParMETIS matches the Fun 3D configure argument. 

A. 7. 3 SUGGAR++-1.0.10 or Higher 

Website: http : / / celeritassimtech.com 

SUGGAR++ is used for overset (chimera) applications and assembles com- 
posite meshes, cuts holes, determines interpolation coefficients, etc. If config- 
uring with SUGGAR++, Fun 3D must also be configured with DiRTlib vl.40 
or higher. 

SUGGAR++ may be compiled as a stand-alone executable and/or as a li- 
brary. For static overset meshes you will need the stand-alone compilation; for 
moving body simulations you will need to compile both the stand-alone exe- 
cutable and the library. See the documentation that comes with SUGGAR++ 
for more information on how to compile the software. 

When configuring Fun 3D, use 

— with-suggar=/path/to/SUGGAR++ 

where /path/to/SUGGAR++ is the directory where SUGGAR++ library archive 
hies (.a hies) reside. In this directory, there must be an archive hie called 
libsuggar.a, which is the serial compilation of SUGGAR++, and there must 
also be an archive hie called libsuggar_mpi.a, which is the MPI compilation 
of SUGGAR+- h 

A. 7. 4 DiRTlib vl.40 or higher 

Website: http : / / celeritassimtech.com 


95 


The DiRTlib library must be linked to Fun 3D in order to use the overset 
connectivity data computed by SUGGAR++-1.0.10 or Higher. See the docu- 
mentation that comes with DiRTlib for more information on how to compile 
the software. 

When configuring Fun 3D, use 
— with-dirtlib=/path/to/DiRTlib 

where /path/to/DiRTlib is the directory where DiRTlib library archive hies 
(.a hies) reside. In this directory, there must be an archive hie called libdirt.a, 
which is the serial compilation of DiRTlib, and there must also be an archive 
hie called libdirt_mpich.a, which is the MPI compilation of DiRTlib. 

A. 7.5 6-DOF 

Contact: Nathan.C.Prewitt@usace.army.mil 

The 6-DOF libraries provide trajectory tracing. When configuring Fun 3D, 
use 


— with-sixdof =/path/to/sixdof 

where /path/to/sixdof is the directory where your 6-DOF installation re- 
sides. 

A. 7.6 KSOPT 

Contact: Gregory.A.Wrenn@nasa.gov 

The KSOPT [21] library is used for multi-objective and constrained Fun 3D- 
based design optimization. If you configure Fun 3D to link to KSOPT, you 
must use the Fortran 90 implementation of KSOPT with its object hies gath- 
ered into a library called libksopt.a. 

When configuring Fun 3D, use 

— with-KSOPT=/path/to/ksopt 

where /path/to/ksopt is the directory where your KSOPT installation re- 
sides. 

A. 7.7 PORT 

Website: http: //www.netlib.org/port 

The PORT library is used for unconstrained FuN3D-based design opti- 
mization. The Netlib site offers a tarball of the PORT library with a Makefile. 
Download the tarball from Netlib, but replace the original Makefile with the 
hie included inside the Fun 3D distribution as Design/PORT. Makefile. If you 
install both the PORT and NPSOL M libraries, you may have to comment out 
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low-level BLAS routines in one of the two packages because the linker will 
report the duplicate versions of these routines. 

When configuring Fun 3D, use 

— with-PORT=/path/to/port 

where /path/to/port is the directory where your PORT installation resides. 

A.7.8 SNOPT™ 

Website: http : //www. sbsi-sol-optimize.com 

The SNOPT M library is used for FuN3D-based design optimization. By 
default the SNOPT M package builds a shared library. Either build SNOPT M 
with the --disable-shared option, or add the the SNOPT M install directory 
to your LD_LIBRARY_PATH environment variable to ensure Fun 3D can End the 
shared library at run time. 

When configuring Fun 3D, use 

— with-SNOPT=/path/to/ snopt 

where /path/to/ snopt is the directory where your SNOPT M installation re- 
sides. 

A.7.9 NPSOL™ 

Website: http: //www.sbsi-sol-optimize.com 

The NPSOL M library is used for constrained FuN3D-based design opti- 
mization. If you install both the PORT and NPSOL M libraries, you may have 
to comment out low-level BLAS routines in one of the two packages because 
the linker will report the duplicate versions of these routines. 

When configuring Fun 3D, use 

— with-NPSOL=/path/to/npsol 

where /path/to/npsol is the directory where your NPSOL M installation re- 
sides. 

A.7.10 DOT/BIGDOT™ 

Website: http: //www. vrand.com/products.html 

The DOT/BIGDOT M library is used for unconstrained or constrained 
FuN3D-based design optimization. When configuring Fun 3D, use 

— with-DOT=/path/to/dot 

where /path/to/dot is the directory where your DOT /BIGDOT M installation 
resides. 
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A. 7. 11 Tecplot™ 


Website: http://www.tecplot.com 

By default, any Tecplot™ output generated from within the flow solver itself 
is written as a text hie. If you have a copy of Tecplot™, you were provided 
with a library archive tecio.a (or tecio64.a for 64-bit versions) that allows 
for binary output. A2 You may configure the Fun3D suite to use the library 
via: 

— with-tecio=/path/to/tecio 

With this option, Tecplot™ solution data written out from the how solver will 
be in binary form. This results in smaller hie sizes and faster importation into 
Tecplot™. 

If you have compiled against the Tecplot™ tecio library, you can still 
request text output via the --ascii_tecplot_output command line option. 

A. 7.12 CGNS 

Website: http://www.cgns.org 

The CGNS library is used for working with hies written in CGNS format. 
CGNS is a convention for writing machine-independent, self-descriptive data 
hies for CFD and includes implementation software. Fun 3D has the capability 
to translate and write CGNS hies. The translation utilities are only compiled 
when CGNS is configured. Version 2.5 or greater of the CGNS library is 
required. To include CGNS, use 

— with-CGNS=/path/to/ cgns 

where /path/to/ cgns is the directory where the CGNS installation resides. 

A. 7.13 sBOOM 

Contact: Sriram.Rallabhandi@NASA.gov 

This package propagates a computed pressure signature to the ground for 
sonic boom simulations. Atmospheric variations are included, and an adjoint 
version is available for coupling into design and grid adaptation. sBOOM is 
distributed as a standalone executable or a static library. Fun 3D is not able 
to interact with the standalone executable; the static library must be linked. 
You may conhgure the Fun 3D suite to use the library via: 

— with-SBOOM=/path/to/ sBOOM 

where /path/to/sBOOM is the directory where the sBOOM installation re- 
sides. 

A2 The tecio library that was shipped with Tecplot360-2008 had a bug that will result 
in error messages when the binary files are written. You must get an updated version of the 
library. 
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Appendix B 


Fun 3D Input Files 


There are a variety of input files necessary for the various codes that make 
up the Fun 3D suite. Table B1 lists frequently used input hies with a short 
description. This chapter will describe the basic formats of each of these hies 
and meaning of the specihc inputs they contain. 


Table Bl: Fun3D input files. 

File Description 


stop.dat 

remove_boundaries_from_f orce_totals 

[project_rootname] .flow* 

fun3d.nml 

moving_body. input 

rotor. data 

tdata 

kinetic_data 
species_transp_data 
species_transp_data_0 
har a jname 1 i st _dat a 


signals a change to the number of iterations / 
time steps that were requested at the beginning 
of the run 

omits boundary faces from total force integra- 
tion 

flow field solution 

primary Fortran namelist (required) 

body motion Fortran namelist 

describes the rotor actuator disk model 

specifies the generic gas model 

specifies the possible chemical reactions in the 

generic gas model 

specifies generic gas model species collision cross 
sections 

specifies a higher-order generic gas model 

species collision cross sections 

controls the radiation models used by the Hara 

library 


* The [project_rootname] is a &project namelist variable, see section B.4.1. 


Fun 3D utilizes Fortran namelists for a large portion of input specification 
because it is defined in the Fortran 90 standard. With all Fortran namelists, 
leaving out or misspelling any namelist (defined with an ampersand preceding 
its name) will result in default values being used for all of the parameters within 
that namelist. For example, if the namelist name linear_solver_parameters 
were to be misspelled as linear _solver_parameter (missing s), then all pa- 
rameters within that namelist would be ignored and retain their default values. 
Leaving out any parameter within a namelist results in the default value for 
that parameter being used. Misspelling or misusing any particular parameter 
will typically cause Fun 3D to issue an error and stop. 
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B.l stop.dat 

This optional file either halts or extends the execution of the solver. The 
stop.dat plain text hie contains a single integer. After every iteration, the 
solver will check to see if this hie exists. If the hie is found in the directory 
that the solver was invoked, the integer is read. If the integer is greater than 
zero and less than or equal to the current iteration, the solver will write the 
current solution, delete the stop.dat hie, and halt execution. If the integer 
is greater than the current iteration, code execution will proceed until the 
iteration matches the integer. The value of the integer may be greater than 
the number of iterations / time steps specihed in fun3d.nml, so that stop.dat 
can be used to extend the execution of the solver if desired. 

Some environments, especially ones with network-mounted filesystems (e.g., 
NFS), may result in a delay with the stop.dat hie being read or being deleted. 

B.2 [project_rootname] .f low 

The optional [projectvrootname] .flow binary hie contains how solution and 
checkpoint information. The [project_rootnarae] is a feproject namelist 
variable, see section B.4.1. This hie is read by the solver to restart compu- 
tations from a previously computed how solution. The contents vary due to 
the checkpoint requirements of the simulation. The hie contains a minimum 
of the current solution and convergence history. It can also contain working 
variables for the turbulence model, solutions from previous iterations for time 
accurate cases, or previous grid positions and velocities for deforming grids. 

B.3 remove _boundaries_from_f or ce .totals 

The optional remove_boundaries_f rom_f orce_totals hie is for specifying bound- 
aries that are not to be included in the calculation of force and moment totals. 
This hie is useful, for example, in situations where there may be a mounting 
sting on a wind tunnel model, but only the forces on the model are actually of 
interest. The forces on the specihed boundaries are still computed and appear 
in the [project_rootname] .forces hie. However, they are not included in 
the totals. The position of the text lines in this hie is significant. So, follow 
this template carefully: 

Remove selected boundaries from the total forces 
Number of boundaries to turn off 
2 

Boundaries to turn off (boundary lumping changes indexes) 

12 

15 
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The third line is the number of boundaries to exclude. The fifth and subsequent 
lines are the patch indexes of the excluded boundaries. 

B.4 fun3d.nml 

The main input namelist file, fun3d.nml, is described in detail below, with de- 
faults listed before the descriptions. The namelist file contains a large number 
of input variables. In general, it is not necessary to specify them all because 
they have suitable default values. Only those variables that are different from 
the defaults need to be specified. An overview of tasks and their associated 
namelists are listed below. 

The project name and grid information: 

&project (B.4.1) 

&raw_grid (B.4. 2) 

&force_moment Jnteg.properties (B.4. 3) 

&grid_transform (B.4. 4) 

&body .transform (B.4. 5) 

The equation set and reference conditions: 

&governing_equations (B.4. 6) 

&reference_physical_properties (B.4. 7) 

&noninertial_reference_frame (B.4. 8) 

The inviscid flux discretization: 

& i nvisc id Tiux .me t ho d (B.4. 9) 

Turbulence model: 

&turbulent_diffusion_models (B.4. 10) 

&spalart (B.4. 11) 

&gammaretsst (B.4. 12) 

Number of and size of time steps or steady iterations: 

&codejrun_control (B.4. 13) 

&nonlinear .solver .parameters (B.4. 14) 
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Linear relaxation controls: 

&linear .solver .parameters (B.4.15) 

Boundary conditions and transition: 

&boundary .conditions (B.4.16) 

&two_d_trans (B.4.17) 

&three_d_trans (B.4.18) 

Flowfield initialization: 

&fio w 4 nit i al iz at ion (B.4.19) 

Force tracking and visualization: 

&component .parameters (B.4.20) 
&time_avg_params (B.4.21) 

&global (B.4.22) 

&volume .output .variables (B.4.23) 
&boundary_output_variables (B.4.24) 

&sampling .output .variables (B.4.25) 
&sampling_parameters (B.4.26) 

&slice_data (B.4.27) 

Overset grid systems and rotorcraft simulation: 

&overset_data (B.4.28) 

&rotor_data (B.4.29) 

Grid adaptation: 

&adapt_metric_construction (B.4.30) 

&adapt .mechanics (B.4.31) 

Design optimization cost functions: 

&massoud .output (B.4.32) 

&sonic_boom (B.4.33) 

&sboorn (B.4.34) 

&equivalent_area (B.4.35) 
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&press box function (B.4.36) 
&pstag Junction (B.4.37) 

Other: 

&speciaLparameters (B.4.38) 
&vortex_generator (B.4.39) 
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B.4.1 ^project 

This namelist allows the user to specify the rootname of the project, which 
forms the majority of input and output filenames. 

&project 

project_rootname = ' def ault_project ' 

/ 


project_rootnarae = ’ default.project ’ 

The project rootname is the root for the grid, restart, and visualization 
files. The manual refers to it as [proj ect .rootname] . The ; def ault.proj ect ’ 
can be replaced with any filename allowed by the hie system. 
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B.4.2 fcraw grid 

This namelist specifies details of the grid format. 


&raw_grid 
grid_f ormat 
data_f ormat 
twod_mode 
swap_yz_axes 

f ieldview_coordinate_precision 

patch_lumping 

ignore_euler_number 

/ 


' vgrid' 

1 default ' 
.false . 
.false . 

' double ' 
'none ' 
.false . 


grid_f ormat = ’vgrid’ 

This specifies the grid file format. The currently supported values are: 

'fast’ for FAST .fgrid/.mapbc files. 

‘ vgrid’ for single- and multi-segmented VGRID .cogsg/.bc/.mapbc files. 

‘fun2d’ for Fun 2D. faces files. 

‘ af lr3 ’ for AFLR3 formatted, unformatted, or C-binary/Fortran-stream 
. ugrid / . r8 . ugrid / . b8 . ugrid / . rnapb c files, 

‘ f elisa’ for Felisa grid files. 

‘ f ieldview’ for FicldView formatted or unformatted .fvgrid_fmt/.fvgrid_unf/.mapbc 
files. 

data_f ormat = ’default’ 

This provides the encoding of the grid file. A particular grid_f ormat 
may only support a subset of encodings. Fun 3D will stop with an error 
message if the data.format is inconsistent with the grid_format. The 
’ default ’ value is changed to an admissible value based on grid_f ormat 
as noted next to each value, 

'ascii’ ASCII text grid file. It is the default for ’felisa’ and ’fun2d’ 
grids. 

'unformatted’ Fortran unformatted grid file. It is the default for 
’fast’, ’vgrid’, and ’f ieldview’ grids. 

' stream’ C-binary/Fortran-stream grid file. It is the default for ’ af lr3’ 
grids. 

' stream64’ 64 bit integer C-binary/Fortran-stream grid file. 


twod_mode = .false. 


Turns on two-dimensional mode for a single layer prism or hex grid. If 
grid_f ormat = ’fun2d’, twod_mode is automatically .true.. 
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swap_yz_axes = .false. 


When .true., this swaps the y- and z-axes for the grid. This option can 
be used to rotate the grid so the z-axes is in the Fun 3D convention for 
angle of attack and lift. 

f ieldview_coordinate_precision = ' double’ 

This specifies floating point precision of reals for FieldView meshes only. 

' double ' for double precision coordinates. 

‘ single' for single precision coordinates. 
patch_lumping = ’none’ 

This enables boundary patch lumping. It combines the grid patches into 
fewer patches to ease the bookkeeping of patch groups, but will effect all 
features that reference boundary patch numbers (e.g., &boundary_conditions). 
The .mapbc hies for any of the supported grid formats may contain an 
optional third column of data, which specifies a family name. The ex- 
ception is the VGRID. mapbc hie, where the family name is mandatory 
and appears in the sixth column. If family names are not present in the 
.mapbc hie, patch_lumping can not be family. 

' none ' for no patch lumping. 

‘ be ’ for physical boundary condition lumping. 

'family' for family name lumping 

ignore_euler_number = .false. 

This will permit the use of grids with a failing Euler number check. See 
section C.7 for a description of the Euler number and its implications. 
Ignoring the Euler number check is not recommended. 
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B.4.3 &force moment integ properties 


Reference lengths and area are defined in this namelist to scale aerodynamic 
force and moment data. 

&f orce_moment_integ_properties 
area_ref erence = 1.0 
x_moment_ length = 1.0 
y_moment_ length = 1.0 
x_moment_ center =0.0 
y_moment_ center = 0.0 
z_moment_center =0.0 

/ 

area_ref erence = 1.0 

This area is used for non-dimensionalization of forces and moments, spec- 
ified in grid units squared. 

x_moment_length = 1.0 

This length in ^-direction is used to nondimensionalize moments about 
y (pitching moment), specified in grid units. 

y_moment_length = 1.0 

This length in ^/-direction is used to nondimensionalize moments about 
x (rolling moment) and 2 (yawing moment), specified in grid units. 

x_moment_center = 0.0 

This specifies the ^-coordinate location of moment center, in grid units. 
y_moment_center = 0.0 

This specifies the ^/-coordinate location of moment center, in grid units. 
z_moment_center = 0.0 

This specifies the z-coordinate location of moment center, in grid units. 
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B.4.4 &grid transform 

This namelist defines a constant grid translation and rotation that is applied 
before the start of the flow solution. For example, original grid may be reori- 
ented to position the geometry at a different angle of attack. 


&grid_transf orm 


ds 

= 

0.0 




sx 

= 

1.0 




sy 

= 

0.0 




sz 

= 

0.0 




theta 

= 

0.0 




tx 

= 

1.0 




ty 

= 

0.0 




tz 

= 

0.0 




xO 

= 

0.0 




yo 

= 

0.0 




z0 

= 

0.0 




scale 

= 

1.0 




transf orm(l , 1 : 4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

transf orm(2, 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

transf orm(3, 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

transf orm(4, 1 : 4) 

= 

0.0, 

0.0, 

0.0, 

1.0 


/ 

ds = 0.0 

This is the translation distance. 

sx = 1.0 

This is the ^-component of a unit vector in the translation direction, 
sy = 0.0 

This is the ^/-component of a unit vector in the translation direction. 
sz = 0.0 

This is the z-component of a unit vector in the translation direction. 
theta = 0.0 

This is the rotation angle (in degrees). A positive rotation is applied by 
the right hand rule with the thumb pointing in direction of rotation axis. 

tx = 1.0 

This is the ^-component of the rotation axis unit vector, 
ty = 0.0 

This is the ^/-component of the rotation axis unit vector. 
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tz = 0.0 

This is the z-component of the rotation axis unit vector. 
xO = 0.0 

This is the ^-coordinate of the rotation origin. 
yO = 0.0 

This is the //-coordinate of the rotation origin. 
zO = 0.0 

This is the z-coordinate of the rotation origin. 
scale = 1.0 

This a scale factor applied to all coordinate values. 

transf orm(l , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a 4x4 transform matrix (see for example [25]). 
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B.4.5 &body transform 

This namelist defines a constant body translation and rotation that is applied 
before the start of the flow solution. For example, original body may be 
reoriented to position the geometry at a different effective angle of attack. 
After repositioning the body, the mesh is deformed once to reflect the new 
position of the body, before beginning the solution. 

&body_tr ansf orm 
n_bodies 
nbndry ( : ) 
boundary_list ( : ) 
ds ( : ) 
sx( : ) 
sy ( : ) 
sz( : ) 
theta( : ) 
tx( : ) 
ty(:) 
tz( : ) 
x0( : ) 
y0( : ) 

z0( : ) 

tr ansf orm ( 1 , 1 : 4 , 1 ) 
transf orm(2, 1:4,1) 
transform (3, 1:4,1) 
transf orm (4, 1:4,1) 

/ 

n_bodi.es = 0 

This is the number of bodies that are to be repositioned at the start of 

the computation. 

nbndry ( : ) =0 

This is the number of boundary patches listed for a given body. 

boundarydList ( : ) = ’’ 

This is a list of boundary patch numbers for a given body. Commas and 

dashes can be used to specify ranges, i.e., ’ 1 , 2 , 5-7 J . 

ds ( : ) - 0.0 

This is the translation distance. 

sx(:) = 1.0 

This is the ^-component of a unit vector in the translation direction. 


= 0 

= 0 
— I I 


= 

o 

o 




= 

o 

T- 1 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

H 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

H 

0.0, 

0.0, 

O 

o 

= 

o 

o 

1.0, 

0.0, 

o 

o 

= 

o 

o 

0.0, 

1.0, 

o 

o 

= 

o 

o 

0.0, 

0.0, 

1.0 
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sy ( : ) = 0.0 

This is the ^/-component of a unit vector in the translation direction. 


sz( : ) = 0.0 

This is the ^-component of a unit vector in the translation direction. 
theta(:) = 0.0 

This is the rotation angle (in degrees). A positive rotation is applied by 
the right hand rule with the thumb pointing in direction of rotation axis. 

tx(:) = 1.0 

This is the ^-component of the rotation axis unit vector. 
ty(:) = 0.0 

This is the ^/-component of the rotation axis unit vector. 
tz( : ) = 0.0 

This is the ^-component of the rotation axis unit vector. 
xO ( : ) = 0.0 

This is the ^-coordinate of the rotation origin. 
yO ( : ) = 0.0 

This is the ^-coordinate of the rotation origin. 
zO ( : ) = 0.0 

This is the z-coordinate of the rotation origin, 
transf orm(l , 1 : 4, 1) = 1.0, 0.0, 0.0, 0.0 
This is a 4x4 transform matrix (see for example [25]). 
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B.4.6 ^governing equations 


This namelist specifies the equation set that describes underlying physics of 
the problem. 

&governing_equations 

eqn_type = 

artif icial_compress 
viscous_terms 

chemical_kinetics = 

thermal_energy_model = 

prandtlnumber_molecular 
schmidt_number 
gas_radiation = 

rad_use_impl_lines = 

multi_component_dif f = 

cpiv_min_f actor 
augment_kinetics_limiting = 
implicit_rate_limiting = 

/ 

eqnrtype = ’compressible 
This specifies the set of governing equations to be solved. 

‘ compressible ’ for compressible, calorically perfect gas. See section 2.1 
for equations and nondimensionalization. 

'incompressible’ for incompressible, calorically perfect gas. [26] See 
section 2.2 for equations and nondimensionalization. The incompress- 
ible solution is affected by the choice of artif icial_compress, see the 
description of this parameter for details. 

‘generic’ for multispecies, reacting gas simulations. See section 2.3 
for nondimensionalization. The tdata input file is required. Fun 3D is 
usually distributed with the ’ generic ’ option disabled. If it is required, 
see section 1.4 for information on obtaining the version of Fun 3D with 
this capability. 

artif icial_compress = 15.0 

This is the artificial compressibility factor, f3, which is only used by the 
eqn.type = ’incompressible’. This parameter must be in the range 
of (100,1). See Anderson, Rausch, and Bonhaus [26] for details. The 
sensitivity of the solution to this parameter will decrease with mesh 
refinement, so consider a refined grid if an unacceptable amount of sen- 
sitivity is experienced. A high sensitivity to this parameter can also 
indicate that the problem is actually compressible and the user is en- 
couraged to check the incompressible solution by performing a low Mach 
compressible simulation. 


' compressible ' 
15.0 

' turbulent ' 

1 finite-rate ' 

1 non-equilib ' 

0.72 

- 1 . 

'off' 

.false . 

.false . 

0.0001 
.false . 

. true . 
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viscous_terras = ’ turbulent ' 

This describes the modeling of the viscosity term in the governing equa- 
tions. 

' inviscid’ no viscosity, for inviscid flow. 

' laminar' apply laminar viscosity, to model laminar flow. 

' turbulent ' include laminar viscosity and model turbulent flow with a 
feturbulent.dif fusion_models. 

chemical_kinetics = 'finite-rate' 

This describes the chemical kinetics, only used when eqn.type = ' generic ' . 
'frozen' for frozen chemical compositions. 

'finite-rate' for finite-rate reacting gases. 
thermal_energy .model = 'non-equilib' 

This describes the thermal energy model, only used when eqn.type = 

' generic ' . 

'frozen' for frozen chemical compositions. 

'non-equilib' for non-equilibrium gases, 
prandtlnumber unolecular = 0.72 

This is the molecular Prandtl number. It must be greater than zero, 
schmidt .number = -1. 

This is the Schmidt number used in the generic gas path. If the user 
wants to override the default path of computing a variable Schmidt num- 
ber from collision cross sections then use this parameter to specify the 
constant Schmidt number. 

gas_radiation = 'off' 

This controls flow held radiation coupling. When active, this option will 
compute radiation source terms and surface heat fluxes after the first 
time step. Radiation source terms are not further updated during the 
rest of the time steps. Radiation source terms are not stored in the 
restart hie, so they need to be recalculated when restarting simulations 
that include how held radiation. Only for eqn .type = 'generic'. 

' of f ’ no radiation calculations. 

'uncoupled' will use the HARA program to compute radiative surface 
heat fluxes, but radiation source terms would not be included in the 
how-held governing equations. 

'coupled' will include radiation source terms in the governing equa- 
tions, with the divergence of the radiative hux being computed by the 
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HARA program. Requires racLuse_impl_lines = .true., only valid if 
all of the domain nodes are included in one and only one line as defined 
by the implicit lines hie. 

rad_use_impl_lines = .false. 

For gas .radiation, the mesh nodes in the lines of sight are read from the 
implicit lines hie. Coupled radiation must use this option. For uncoupled 
radiation, the lines of sight can either be read from the implicit lines hie 
when .true., or the lines of sight will be generated during the FUN3D 
run when .false. Only for eqnrtype = 'generic 5 . 

multi_component_dif f = .false. 

When .true., engage multi-component diffusion using sub-iteration of 
Stefan-Maxwell Equations as described by Sutton and Gnoffo. [27] Oth- 
erwise, use binary diffusion with mass fraction averaged correction to 
force sum of diffusion hux to equal zero. Only for eqn.type = 'generic'. 

cpivnnin.f actor = 0.0001 

This variable sets the minimum value of the vibrational-electronic heat 
capacity as a fraction of the translational-rotational heat capacity for 
each species i. In some cases, ramping this value up to 0.01 can help 
suppress undershoot of vibrational temperature upstream of a strong 
shock. The vibrational-electronic heat capacity must be positive for 
stability. Only for eqn.type = 'generic'. 

augment _kinetics_limiting = .false. 

When .true., augment chemical kinetic source term limiting. Only for 
eqn.type = 'generic'. 

implicit_rate_limiting = .true. 

When .true., limit chemical rates if extrema exist in formulation Only 
for eqn_type = 'generic'. 
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B.4.7 Preference physical properties 


This namelist is used to specify reference conditions and nominal freestream 
flow conditions in a user-defined unit system. It is also used to convert between 
grid units and flow solver units. 


&ref erence_physical_properties 


dim_ input _type 

= 

' nondimensional 

gridlength_conversion 

= 

1.0 

mach_number 

= 

0.0 

reynolds_number 

= 

0.0 

velocity 

= 

0.0 

density 

= 

0.0 

temperature 

= 

273.0 

temperature_units 

= 

' Kelvin 1 

angle_of _attack 

= 

0.0 

angle_of _yaw 

= 

0.0 


/ 


dim_input_type = ’ nondimensional ’ 

This is the system of measurement for the reference conditions. Cur- 
rently, it must be ’ dimensional-SI ’ for eqn_type = ’ generic ’ and 
’ nondimensional ’ otherwise. This input is intended for future expan- 
sion. The temperature is always input as a dimensional quantity. 

' nondimensional ’ requires maclunumber and reynolds_number to be 
defined. 

'dimensional-SI’ requires dimensional velocity and density to be 
defined. 

gridlength_conversion = 1.0 

For dim_input_type = ’dimensional-SI’, this is the conversion fac- 
tor to scale the grid and it should be set to meters per grid unit. It 
is used for providing heat flux in proper units and other tasks. For 
dim_input_type = ’nondimensional’, this should be set to 1.0, be- 
cause the grid is already in nondimensional grid units. 

mach_number = 0.0 

This is the reference Mach number defined as velocity/speed-of-sound. It 
is only allowed for dim_input_type = ’nondimensional’ and eqnvtype 
= ’ compressible’ . It must be set to a positive value. 

reynolds_number = 0.0 

This is the reference Reynolds number, per one unit of the grid. Not 
correctly accounting for the unit of the grid has been a point of confusion 
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in the past. For example, when the grid units are feet, Reynolds number 
should be specified per foot. This input is only used if dim_input_type = 
’ nondimensional ’ and is ignored by eqn_type = ’ generic’ . It must 
be set to a positive value. 

velocity = 0.0 

This is the reference velocity, in m/s. Only used for dim_input_type = 
’ dimensional-SI ’ and eqn_type = ’generic’. 

density = 0.0 

This is the reference density, in kg/m 3 . Only used for dim_input_type 
= ’ dimensional-SI ’ and eqn.type = ’generic’. 

temperature = 273.0 

This is the reference temperature, in units of temperature_units. 
temperature units = ’Kelvin’ 

The units used to specify temperature. 

'Kelvin’ for SI units. 

' Rankine ’ for the English system. 
angle_of ^attack = 0.0 

This is the freestream angle of attack in degrees. 

angle_of_yaw =0.0 

This is the freestream angle of yaw (side-slip) in degrees. 
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B.4.8 ^noninertial reference frame 

FUN3D can perform simulations in noninertial reference frame rotating at a 
constant rate, fl The noninertial reference frame simulation can be run as a 
steady state problem if the freestream velocity crossed with the rotation vector 
is zero, Uoo x fl = 0. In a practical sense, freestream velocity should be zero 
or parallel to the axis of rotation. Using a standard inertial reference frame 
requires the same problem to be run as an unsteady simulation at a larger 
computational cost. Typical uses would be the simulation of an isolated rotor 
in hover (without forward motion) or an aircraft performing a steady-state 
pitching maneuver or constant roll about the wind axis. 


&noninertial_ref erence_frame 


noninertial 


.false . 


rotation_center_x = 0.0 
rotation_center_y = 0.0 
rotation_center_z = 0.0 
rotation_rate_x = 0.0 
rotation_rate_y = 0.0 
rotation_rate_z = 0.0 


noninertial = .false. 

When .true., use a noninertial reference frame. The default is the inertial 
reference frame. 


rotation_center_x = 0.0 

This is the x of the steady rotation rate center point. 


rotation_center_y = 0.0 

This is the y of the steady rotation rate center point. 


rotation_center_z = 0.0 

This is the z of the steady rotation rate center point. 
rotation_rate_x = 0.0 

This is the steady noninertial rotation rate about the rotation center x- 
axis in reference speed of sound per grid unit (eqn_type = J compressible ’ ) 
or reference speed per grid unit (eqnvtype = ’ incompressible J ). 


rotation_rate_y = 0.0 

This is the steady noninertial rotation rate about the rotation center y- 
axis in reference speed of sound per grid unit (eqn_type = ’ compressible ’ ) 
or reference speed per grid unit (eqn.type = ’ incompressible J ). 
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rotation_rate_z = 0.0 

This is the steady noninertial rotation rate about the rotation center pr- 
axis in reference speed of sound per grid unit (eqnrtype = ’ compressible ’ ) 
or reference speed per grid unit (eqnrtype = ’ incompressible J ). 
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B.4.9 fcinviscid flux method 


This namelist controls the construction of the inviscid fluxes and flux Jaco- 
bians. 


&inviscid_f lux_method 
f lux_construction 
f lux_construction_lhs 
kappa_umuscl 
f lux_limiter 

f reeze_limiter_iteration = 

f irst_order_iterations 

mult idm_opt ion 

f ixed_direction 

recalc_dir_freq 

adptv_entropy_f ix 

rhs_u_eigenvalue_coef 

lhs_u_eigenvalue_coef 

rhs_a_eigenvalue_coef 

lhs_a_eigenvalue_coef 

entropy_fix 

re_min_vswch 

re_max_vswch 

pole_gradient 


1 roe ' 

' vanleer ' 
- 1.0 
' none ' 

-1 

0 

1 

. true . 

1 

.false . 

0. 

0 . 

0 . 

0 . 

.false . 
50 . 

500 . 
.false . 


f lux.construction = ’roe’ 

This specifies the inviscid flux residual construction method. 

‘ roe ’ for Roe flux difference splitting. 

‘ vanleer ’ for van Leer flux vector splitting. 

‘hllc’ for HLLC. 

‘ auf s ’ forAUFS. 

‘ ldf ss ’ for LDFSS. 

‘ dldf ss J for dissipative LDFSS. 

‘aldfss’ for LDFSS with an adaptive entropy fix. 

< roe_ec J for entropy-consistent Roe scheme. 

‘ stvd’ for Yee’s symmetric total variation diminishing scheme. 
‘ stvdnnodif ied’ for a modified version of STVD. 

< multidIn , for Gnoffo’s multidimensional scheme. 
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f lux_construction_lhs = ’vanleer' 

This specifies the inviscid flux Jacobian construction method. A ’ consistent ’ 
method yields the best asymptotic iterative convergence rate of the non- 
linear residual, but a more diffusive flux may stabilize a poorly converging 
or diverging linear system iterative scheme. 

‘ consistent ’ for a consistent linearization with the residual construc- 
tion method. 

‘vanleer’ for Van Leer. 

‘ roe ’ for Roe linearization. 

‘hllc’ for HLLC. 

‘ auf s ’ forAUFS. 

‘ ldf ss ’ for LDFSS. 

kappammuscl = -1.0 

Controls the amount of upwinding in the unstructured-grid MUSCL re- 
construction scheme. The default will adjust kappa.umuscl internally 
to 0.5 for 3D mixed-element grids or 0.0 for all other grid types. 0.0 is 
the upwind-biased (Fromm) discretization, 1.0 is the (unstable) central- 
difference discretization, and the range [0,1] is a blend of the two. 

f luxLLimiter = ’none’ 

This selects the flux limiter. The limiters that begin with the letter h, 

’ barth ’ , and J venkat ’ are stencil-based limiters (they apply a limiter 
to each edge in a node’s the reconstruction stencil and store the most 
restrictive edge limiter value at the node). Other limiters are evaluated 
in a strictly edge-based manner. The h-series of limiters automatically 
turns on a heuristic pressure based limiter that is used to augment the 
selected flux limiter. [28] The node-based limiters can be frozen with 
the f reeze_limiter_iteration namelist variable to possibly improve 
“ringing” nonlinear iterative convergence. The adjoint solver is only 
compatible with a frozen limiter. For hypersonic flows computed us- 
ing the calorically perfect gas path, the hvanleer or hvanalbada flux 
limiters are recommended. 

‘ none ’ for no limiter. 

‘ barth ’ for the Barth limiter. 

‘ venkat J for the Venkatakrishnan [29] limiter. This limiter is dimen- 
sional and should be scaled if the grid is not normalized to a characteristic 
length of your model. The --sraooth_limiter_coef f command line op- 
tion should be set to a reciprocal of a characteristic length, i.e. , l/(Mean 
Aerodynamic Chord) . 
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‘ hminmod’ for the stencil-based min- mod limiter augmented with a heuris- 
tic pressure limiter. 

‘hvanleer’ for the stencil-based van Leer limiter augmented with a 
heuristic pressure limiter. 

‘hvanalbada’ for the stencil-based van Albada limiter augmented with 
a heuristic pressure limiter. 

‘ hvenkat ’ for the Venkatakrishnan limiter augmented with a heuristic 
pressure limiter. 

‘mininod’ for the min-mod limiter. 

‘vanleer’ for the van Leer limiter. 

‘vanleer_gg’ for van Leer limiter that also turns on Green-Gauss gra- 
dients for inviscid reconstruction. 

‘vanalbada’ for the van Albada limiter. 

freeze_limiter_iteration = -1 

The node-based limiters can be frozen by setting f reeze_limiter_iteration 
to zero or an iteration number. A negative value does not freeze the lim- 
iter. Zero is used to retain the limiter held contained in the restart 
hie. Freezing can possibly improve “ringing” nonlinear iterative conver- 
gence. [29] If a unrealizable reconstruction (negative density or pressure) 
is encountered the limiter held will be locally updated at the node ex- 
periencing the problematic reconstruction. The adjoint solver is only 
compatible with a frozen limiter. 

f irst_order_iterations = 0 

This is the number of iterations to use hrst-order spatial accuracy prior 
to using second-order spatial accuracy. If second-order spatial accuracy 
in not required, set this to a value larger than the number of steps. 

This option is useful for starting difficult supersonic how simulations. 

For time accurate cases (time_accuracy not equal to ’steady’), this 
is the number of hrst-order accurate sub-iterations to run for each time 
step. 

multidm_option = 1 

This controls the multidm reconstruction weighting. 

‘ 1 ’ virtual node averaging. 

‘ 2 ’ weighted average of edges. 

f ixed_direction = .true. 

This specihes the use of Cartesian directions in multdm reconstruction. 
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recalc_dir_freq = 1 

This sets the frequency of direction recalculation in the multidm scheme. 
adptv_entropy_f ix = .false. 

This activates the adaptive entropy fix for Roe’s scheme. 

rhs_u_eigenvalue_coef = 0. 

This is the contact /shear eigenvalue smoothing coefficient for the adap- 
tive entropy fix and the roe residual. 

lhs_u_eigenvalue_coef = 0. 

This is the contact /shear eigenvalue smoothing coefficient for the adap- 
tive entropy fix and the roe Jacobian. 

rhs_a_eigenvalue_coef = 0. 

This is the acoustic eigenvalue smoothing coefficient for the adaptive 
entropy fix and the roe residual. 

lhs_a_eigenvalue_coef = 0. 

This is the acoustic eigenvalue smoothing coefficient for the adaptive 
entropy fix and the roe Jacobian. 

entropy_fix = .false. 

This activates the entropy fix for the stvd flux. 
re_min_vswch = 50. 

For the stvd flux, eigenvalue limiting is turned off below this cell Reynolds 
number. 

re_max_vswch = 500. 

For the stvd flux, eigenvalue limiting is fully engaged above this cell 
Reynolds number. 

pole_gradient = .false. 

If true, use limiting form of continuity equation across pole in association 
with symmetry_l_strong, symmetry _2_strong, or symmetry_3_strong. 
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B.4.10 ^turbulent diffusion models 

When viscousrterms = ’turbulent’, this namelist is used to set the form 
of the turbulence model. 

&turbulent_dif f usion_models 
turbulence_model 
turb_model 

turb_intensity = 

turb_viscosity_ratio = 

turb_compress_model 
turb_conductivity_model = 
prandtlnumber_turbulent = 
schmidtnumber_turbulent = 

/ 

turbulenceunodel = ’ sa 

This selects the form of the turbulence model. The naming convention 
of http://turbmodels.larc.nasa.gov/ is used for the models described 
on the website. 

' sa’ for Spalart-Allmaras model. [30] See the fespalart namelist in sec- 
tion B.4.11 for additional controls. 

'sa-catris’ for Spalart-Allmaras Catris-Aupoix model. [31] 

'des’ for Spalart-Allmaras based DES model. [32] See the fespalart 
namelist in section B.4.11 for additional controls. Not available for 
eqn_type= ’ generic ’ . 

' sa-neg’ for Spalart-Allmaras model with negative turbulence variable 
provisions. [33] Not available for eqn_type= ’ generic ’ . 

'des-neg’ for Spalart-Allmaras based DES model with negative turbu- 
lence variable provisions. [32,33] Not available for eqn_type= ’ generic ’ . 

' menter-sst ’ option is no longer valid, use sst or sst-v 

' sst’ Menter SST Two-Equation Model with strain source term. [34] 

'sst-v’ Menter SST Two-Equation Model with vorticity source term. 
[35] Not available for eqn_type= ’ generic ’ . 

'wilcoxl988’ Wilcox (1988) k-omega Two-Equation Model. [36] Not 
available for eqn_type= ’ generic ’ . 

' wilcoxl988-v’ Wilcox (1988) k-omega Two-Equation Model with vor- 
ticity source term. [36] Not available for eqn_type= ’ generic ’ . 

'wilcox2006’ Wilcox (2006) k-omega Two-Equation Model. [37] Not 
available for eqn_type=’ generic ’ . 


1 sa 1 

1 deprecated-use-turbulence_model 1 
0.001 
0.001 
'off 1 
'off' 

0. 9 

1 . 
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‘ wilcox2006-v J Wilcox (2006) k-omega Two-Equation Model with vor- 
ticity source term. [37] Not available for eqn_type= 5 generic ’ . 

‘hrles’ for Menter SST-based hybrid- RANS/LES model. Does not 
work with eqn_type= ’ generic ’ . 

‘ gamraa-ret-sst ’ for Langtry and Menter SST transition model. [38] 

See the fegaramaretsst namelist in section B.4.12 for additional controls. 

Not available for eqn_type =:i generic’ . 

‘ baldwin-lomax’ Baldwin-Lomax algebraic model. Available only for 
eqn_type= ’ generic 5 . 

‘ cebeci- smith J Cebeci-Smith algebraic model. Available only for eqnrtype 
generic. 


turbunodel = ’ deprecated-use-turbulenceunodel J 

This is a deprecated namelist variable for turbulence _model. It is in- 
cluded for backwards compatibility with fun3d.nml hies, but may be 
removed in a future version. 


turb.intensity = 0.001 


This sets the freestream turbulence intensity, where k is the tur- 

bulent kinetic energy. Only applies to eqnvtype^ generic ’ . 


turb_viscosity_ratio = 0.001 

This sets the freestream ratio of turbulent viscosity to molecular viscos- 
ity. Only applies to eqn_type= ’ generic ’ . 


turb_compress_model = ’off’ 

This controls the turbulence compressibility model. Only applies to 
eqn_type= ’ generic J . 

‘ of f ’ for no correction. 

'ssz’ for SSZ (use with Spalart-Allmaras models). 

'zeman' for Zeman (use with k — e models). 

‘ wilcox J for Wilcox (use with SST-based models). 

' sarkar J for Sarkar (use with k — e models). 


turb.conductivityunodel = 'off’ 

This controls whether a turbulence conductivity model is employed. 
Only applies to eqn_type= ’ generic ’ . 

‘off’ to turn off a turbulence conductivity model. 

‘ on ’ to turn on a turbulence conductivity model. 
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prandtlnuraber_turbulent = 0.9 
This is the turbulent Prandtl number. 
schmidtnumber_turbulent = 1. 

This is the turbulent Schmidt number. Only applies to eqn_type= ’ generic ’ . 
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B.4.11 &:spalart 

This namelist is used to modify details of the SA and SA based DES turbulence 
models. 


fespalart 

turbinf 

dacles_mariani 


= 3.0 


= .false. 
= .false. 
= .false. 
= .false. 
= 0.975 


sarc 

ddes 


ddes_modl 

cddes 


/ 


turbinf = 3.0 

This is the freestream turbulence value for the SA model. 
daclesanariani = .false. 

This activates the Dacles-Mariani [39,40] rotation correction (denoted 
SA-R by http://turbmodels.larc.nasa.gov/). 

sarc = .false. 

This activates the rotation/curvature correction [41] (denoted SA-RC by 
http : / / turbmodels.larc.nasa.gov/). 

ddes = .false. 

This changes the turbulence_model= ’ des ’ into Delayed DES [42] (DDES) 
ddes_modl = .false. 

This changes the turbulence_model=’des’ into Modified Delayed DES 
[43] (MDDES). It also requires ddes = .true. This option should be used 
with caution. Most experience with this model is for large separated 
flows encountered in wake regions of bluff bodies, such as cylinders and 
landing gears. Further validation is required for other situations. There 
is sensitivity to the parameter cddes. 

cddes = 0.975 

This is Cmdd hi [43]. It used with the ddes_modl = .true. 
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B.4.12 &gammaretsst 


This namelist modifies the details of the turbulence_model = ’ gamma-ret-sst ’ 
transition turbulence model of Langtry and Menter. [38] Correctly setting the 
freestream levels of turbulence is key to the transition location of this model. 
Ideally, freestream turbulence levels are measured in an experiment. 

&gammaretsst 

set_k_inf _w_turb_intsty_percnt = -1.0 
set_w_inf _w_eddyviscosity = -1.0 

/ 


set_k_inf _w_turb_intsty_percnt = -1.0 

This is the freestream turbulence level as a percentage. A positive value 
will set koc = 1.5(0.01 * Ad * set_k_inf _w_turb_intsty_percnt) 2 . 

set_w_inf _w_eddyviscosity = -1.0 

This is the freestream eddy viscosity as the ratio between turbulent 
eddy viscosity to laminar viscosity. A positive value will set = 
/c 00 /set_k_inf _w_turb_intsty_percnt. If not available, a value in the 
range of 0.05 to 5 is commonly used, but the appropriate value is case 
specific. 
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B.4.13 &code run control 


This namelist controls the length of the simulation. Restart options, Jacobian 
update strategy, and angle of attack continuation can also be specified. 

&code_run_control 
steps 

stopping_tolerance 
duration_limit_in_minutes = 
no_restart 
restart_write_f req 
restart_read 
smart_j update 
j acobian_eval_f req 
jupdate_startup_steps 
jupdate_amut_max_ change 
jupdate_cf l_inv_change 
df duc3_ j acobians 
alpha_sweep 
cycle_ increment 
alpha_ increment 
alpha_max 
alpha_min 
alpha_switchbacks 

/ 

steps = 500 

This is the number of time steps or steady iterations to perform. 

stopping.tolerance = l.e-15 

This instructs the solver to terminate before all steps are complete when 
root mean square (RMS) of the residual is less than this tolerance. For 
Euler or laminar perfect gas simulations, only the continuity equation 
residual is examined. In all other simulations, each equation RMS (con- 
tinuity, energy, etc.) must meet this tolerance. 

duration_limit_inuninutes = -1.0 

This is the maximum run duration limit in minutes (a negative value 
is unlimited). This limit can terminate the solver before all steps are 
complete, which may be helpful if the solver is run as a batch system job 
with a time limit. Additional time is required to complete the current 
iteration and write restart hie. So, allow an extra time margin for code 
shutdown. MPI required. 

no_restart = .false. 

When this is .true., no restart checkpoint hie is written. 


500 
l.e-15 
- 1.0 
.false . 
250 
' on ' 

. true . 

0 

10 

0.20 

5.0 

.false . 
.false . 
50 

0.25 

180.0 
-180.0 
0 
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restart_write_f req = 250 

The restart checkpoint and convergence history files will be written to 
disk every restart_write_freq time steps. 

restart_read = ’on’ 

This defines the solution at the first time step. 

‘ on ’ to initialize the simulation with a solution read from the restart 
file. The current convergence history will be concatenated with the prior 
solution history. 

‘ on_nohistorykept ’ to initialize the simulation with a solution read 
from the restart file. The previous history (e.g., residuals, forces, mo- 
ments) will be discarded. 

‘ of f ’ for no restart file read. The solution will be initialized as freestream 
or as specified in the &f low_initialization namelist. 

smart _j update = .true. 

This option allows the code to automatically adjust the Jacobian update 
frequency based on residual reduction. 

jacobian_eval_f req = 0 

This is the frequency of Jacobian evaluation based on time steps. It 
should be set to zero when smart _j update = .true. 

jupdate_startup_steps = 10 

The Jacobians are evaluated at every time step for the first jupdate_startup_steps, 
which aids robustness during initial start transients. 

jupdate_amut_max_change = 0.20 

For turbulent flow, the Jacobians are refreshed when maximum eddy 
viscosity changes by this amount from the maximum eddy viscosity cor- 
responding to the last jacobian evaluation. 

jupdate_cf l_inv_change = 5.0 

The Jacobians are refreshed when the time term associated with cfl of 
the adaptive strategy and the time term of the jacobian evaluation differ 
by this amount. 

dfduc3_jacobians = .false. 

This option only affects eqn.type = ’incompressible’. When .true., 
approximate Jacobians are computed that may improve the convergence 
of some cases. 
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alpha_sweep = .false. 

This option activates a procedure to adjust angle.of .attack during a 
simulation. It can be used to calculate a drag polar in a single execution 
or explore a hysteresis loop. It is controlled by the following options. 

cycle.increment = 50 

When alpha_sweep=.true, 

cycle increment < 0 increments angle.of .attack after residuals have 
reached the stopping.tolerance. 

cycle increment > 0 is the number of iterations between increments 
to alpha. 

cycle increment = 0 is an inadmissible value, 
alpha.increment = 0.25 

When alpha_sweep=.true., increment angle.of .attack by these many 
degrees at a point controlled by cycle.increment. 

alphannax = 180.0 

When alpha_sweep=.true., this is the maximum value of angle.of .attack. 
alpha_min = -180.0 

When alpha_sweep=.true., this is the minimum value of angle.of .attack, 
alpha.switchbacks = 0 

When alpha_sweep=.true., this is the number of directional changes in 
the angle.of .attack sweep. When alpha.switchbacks > 0, alpha.increment 
changed in sign after reaching alpha_max or alphannin. This allows ex- 
ploration of hysteresis loops. 
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B.4.14 ^nonlinear solver parameters 

This namelist defines the temporal accuracy of the solution advancement 
scheme. The subiterations and time step size of time accurate simulations 
can also be specified. The ramping of the pseudo time advancement CFL 
number is also set. Density and pressure floors on the update and relation 
factors are available. 


fenonl inear _solver_parameters 

time_accuracy = 'steady' 

time_step_nondim =0.0 

subiterations = 0 

temporal_err_control = .false. 

temporal_err_f loor =0.1 

schedule_number = -1 

schedule_iteration(l : 2) = 1, 50 
schedule.cf 1 (1:2) = 200.0, 200.0 

schedule_cf lturb(l : 2) =50.0, 50.0 

f _allow_minimum_m =0.01 

invis_relax_f actor = 1.0 

vise relax factor = 1.0 


time.accuracy = ’steady’ 

This defines the temporal scheme. 

‘ steady’ for steady state calculations. This is a local time step pseudo- 
time advancement scheme that is not time accurate. 

‘ lstorder ’ is a first-order backward differencing scheme (backward Eu- 
ler) for time-accurate temporal time integration. 

‘ 2ndorder ’ is a second-order backward differencing scheme (BDF2 in 
[44]) for time-accurate temporal time integration. 

‘ 2ndorderOPT ’ is an optimized second-order backward differencing (BDF2opt 
in [45]) for time-accurate temporal time integration. This scheme is 
second-order accurate in time but has an order-of-magnitude lower lead- 
ing coefficient than standard BDF2. 

‘3rdorder’ is a third-order backward differencing scheme (BDF3 in 
[44]) for time-accurate temporal integration. 

‘ 4thorderMEBDF4’ is a fourth-order modified extended backward differ- 
encing scheme (MEBDF4 in [44]) for time-accurate temporal integration. 

‘ 4thorderESDIRK4’ is a fourth-order explicit, singly diagonally implicit 
Runge-Kutta (ESDIRK4 in [44]) for time-accurate temporal integration. 
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time_step_nondim = 0.0 


This is the nondimensional time step for time accurate simulations. 
It is ignored when time_accuracy = ’steady 5 . The nondimension- 
alization of this parameter depends on eqnvtype. When eqnvtype = 

5 compressible 5 , it is where a re / is the reference speed of sound, 

and L is unit 1 of the grid. When eqn.type = 5 incompressible 5 or 
’generic’, it is dt^-, where u re f is the reference velocity. See sec- 
tion 2.4 for more details and guidance on appropriate values. 

subiterations = 0 

Number of subiterations applied to solve the implicit time integration. 
It is ignored when time_accuracy = ’steady’. A constant CFL time 
step is used in each subiteration. By the end of a convergent subiteration 
process the pseudo time term drops out, giving the correct temporal 
discretization. 

temporal_err_control = .false. 

This governs whether the specified number of subiterations are run for 
each time step (.false.), or, if the temporal error is monitored and the 
subiterations are stopped when a specified tolerance is reached (.true.). 
It is ignored when time_accuracy = ’ steady’ . 

temporal_err_f loor =0.1 

This sets the tolerance for which time-accurate subiterations are stopped. 
The tolerance is given as a multiplicative factor of the flow residuals 
(mean and turbulence). It is ignored when time.accuracy = ’ steady’ . 

schedule_number = -1 

This variable is deprecated and will be removed. Please remove it from 
your namelist. A warning will be provided if this variable is set. 

schedule_iteration(l : 2) = 1 , 50 

These are the iteration or subiteration numbers at which CFL numbers 
are specified. When time _ac curacy = ’ steady ’, this controls the CFL 
number of the pseudo-time terms over iterations. When running time- 
accurately, this controls the CFL number of the pseudo-time terms of the 
linear system over subiterations. The parameter schedule_iteration(l) 
must be one, because it defines the starting CFL number at the first 
iteration or subiteration. The actual CFL number is determined by 
a linear ramp from schedule_cfl(l) at schedule_iteration(l) to 
schedule.cf 1 (2) at schedule_iteration(2) . The CFL number is held 
constant at schedule_cf 1 (2) after schedule_iteration(2) . 
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schedule.cf 1 (1 : 2) = 200.0, 200.0 

This controls the ramping and final CFL number of the meanflow equa- 
tions. See the description for schedule_iteration. 

schedule_cflturb(l : 2) = 50.0, 50.0 

This controls the ramping and final CFL number of the turbulence model 
equations. See the description for schedule.cf 1 in schedule_iteration. 

f _allow_minimum_m = 0.01 

This limits the solution update to prevent pressure and density from 
dropping below this fraction of their freestream values. Applied to 
eqnvtype = ’ compressible ' only. 

invis_relax_f actor = 1.0 

This is the relaxation factor of inviscid terms. It scales the nonlinear 
update of the inviscid terms by this fraction and is only used for eqn.type 
= 'generic 5 . 

visc_relax_f actor = 1.0 

This is the relaxation factor of viscous terms. It scales the nonlinear 
update of the viscous terms by this fraction and is only used for eqn.type 
= 'generic'. 
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B.4.15 &linear solver parameters 

The Fun 3D solution process involves constructing a linearization of the resid- 
ual with appropriate time terms and then solving this linear system to compute 
the solution update. This namelist controls the solution process of this linear 
system. The linearization is grouped in to the meanflow equations and the 
turbulence model equations. 

&linear_solver_parameters 
meant low_sweeps = 15 
turbulence_sweeps = 10 
linear_projection = .false. 
line_implicit = 'off' 

/ 

meanf low.sweeps = 15 

This is the number of the linear system red-black relaxations at each 
steady iteration or time step of the meanflow equations when there is no 
turbulence model or a loosely coupled turbulence model. For eqn_type 
= ’ generic’ or fully coupled meanflow and turbulence relaxation, this 
refers to all equations (meanflow and turbulence). 

turbulence_sweeps = 10 

This is the number of the linear system red-black relaxations at each 
steady iteration or time step of the turbulence equations, when the tur- 
bulence equations are loosely coupled. It has no effect for fully coupled 
meanflow and turbulence relaxation or a simulation without a turbulence 
model. 

linear.projection = .false. 

This options uses a Krylov projection method generalized conjugate gra- 
dient (GCR) to stabilize and improve convergence of linear system. This 
will execute multiple sets of red-black relaxation to form the CGR search 
directions, until a convergence criteria is met. 

line.implicit = ’off’ 

This option selects the relaxation scheme. 

'off’ uses point implicit relaxation. 

‘ on’ uses line implicit relaxation where lines are defined and point relax- 
ation elsewhere. The line implicit feature requires construction of these 
lines prior to running Fun 3D. The lines are stored in the a file named 
[project_rootname] ,lines_fmt, see section 4.4 for a description. The 
af lr3_line_extraction utility is distributed with Fun 3D to generate 
these lines. 
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B.4.16 ^boundary conditions 


This namelist provides auxiliary information to the boundary conditions. Re- 
fer to section 3 for the definition of boundary numbers and other information. 


&boundary_conditions 

total_pressure_ratio ( : ) 

total_temperature_ratio( : ) 

subsonic_inf low_velocity ( : ) 

alpha_bc ( : ) 

beta_bc( : ) 

thetal ( : ) 

theta2 ( : ) 

theta3( : ) 

pt_amplitude ( : ) 

pt_f requency ( : ) 

pt_phase( : ) 

tt_amplitude ( : ) 

tt_f requency ( : ) 

tt_phase( : ) 

ampl ( : ) 

freq( : ) 

phase ( : ) 

random ( : ) 

ramp_constant ( : ) 

pressure_relaxation( : ) 

nozzle_symmetry 

inlet_symmetry 

npr_set 

massf low_set_in 
static_pressure_ratio ( : ) 
inlet_solution_method( : ) 
mach_bc( : ) 
massf low( : ) 
massf low_set_out 
massf low_dimens ions 
grid_units 
q_set ( : , 1 : 5) 
q_set_ramp( : ) 
prof ile_type ( : ) 
patch_center ( : ,1:3) 
patch_scale ( : ) 
prof ile_rho_coef ( : ,0:6) 
prof ile_u_coef ( : ,0:6) 
prof ile_p_coef ( : ,0:6) 
prof ile_coef ( : ,1:3) 


= 1.0 
= 1.0 
= 'normal' 

= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= .false. 

= 1.0 
= 1.0 
= 1.0 
= 1.0 
= 0.0 
= 0.0 
= 1.0 
= 'mach ' 

= 0.0 
= 0.0 
= 0.0 
= 'nondim' 

= 'nondim' 

= 0.0 
= 0 

= ' radial_polynomial ' 
= 0.0 
= 1.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
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wall_velocity ( : ,1:3) 
rotation_center ( : ,1:3) 
rotation_vector ( : ,1:3) 
rotation_rate ( : ) 
unorm_bc( : ) 
wall_temperature ( : ) 
wall_temp_f lag( : ) 
wall_radeq_f lag( : ) 
wall_emissivity ( : ) 
wall_emissivity_b( : ) 
wall_emissivity_c ( : ) 
wall_emissivity_d( : ) 
wall_temp_relax( : ) 
wall_catalysis_model ( : ) 
catalytic_eff iciency_o( : ) 
catalytic_eff iciency_n( : ) 
ablation_option_map( : ) 
steady_ablation 
ablation_recession_freq 
st art _re cession 
bprime_f lag_map( : ) 
compute_mdot_initial_map ( : ) 
f req_mdot_map ( : ) 
f req_wall_map ( : ) 
uncoupled_ablation_f lag_map( : ) 
wall_blowing_model ( : ) 
virgin_density_wall ( : ) 
char_density_wall ( : ) 
CHONSi_frac_char_map( : ,1) 
CHONSi_frac_pyrolysis_map( : , 1) 
h_ablation_map( : , : ) 
indot _pres sure _map ( : , : ) 
t_sublimation_map ( : , : ) 
plenum_tO( : ) 
plenum_pO( : ) 
plenum_id( : ) 
f ixed_in_id( : ) 
f ixed_in_rho ( : ) 
f ixed_in_uvw( : , 1 : 3) 
f ixed_in_t ( : ) 
f ixed_in_tv( : ) 
f ixed_in_turb( : ,1:7) 
specif ied_transition( : ) 
impose_pressure_gradient 
pressure_gradient 


0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

.false . 

.false . 

0.8 

0. 

0. 

0. 

0.001 

' super-catalytic ' 
0. 

0. 

0 

.false . 

3000 

0 

1 

1 

5000 

50 

0 

'none ' 

1 . 

1 . 

1 . 

1 . 

0. 

0. 

0. 

1000. 

1000 . 

0 

0 

0. 

0. 

0. 

0. 

0. 

.false . 

.false . 

0.0 
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solidity ( : ) 


0.0 

0.0 


porous_coef f icient ( : ) 
x_ const ant _boundary( : ) 
y_constant_boundary ( : ) 
z_constant_boundary ( : ) 
tol_const_ coord 


.false . 
.false . 
.false . 
1.0e-6 


/ 


total_pressure_ratio( : ) = 1.0 

This is the ratio of plenum total pressure to reference pressure used by 
7011 boundary condition. Inflow Mach number must be less than one. 

total_temperature_ratio ( : ) = 1.0 

This is the ratio of plenum total temperature to reference temperature 
used by 7011 boundary condition. Inflow Mach number must be less 
than one. 

subsonic.inf low_velocity ( : ) = ’ normal ’ 

This sets the direction of the inflow velocity. 

‘ normal ’ for inflow normal to each element face in the patch 

'alpha, beta’ the angle of the inflow is specified by alpha.bc and 
betaibc as shown in Fig. 4. 

'interior’ the angle of the inflow is specified by the Euler angles 
thetal, theta2, and theta3 as shown in Fig. B5. 

'offset’ the angle of normal inflow to the patch boundary is rotated 
by the Euler angles thetal, theta2, and theta3 as shown in Fig. B5. 

alpha_bc(:) = 0.0 

When subsonic_inf low_velocity = ’ alpha, beta’ , this is the angle 
of attack in radians for 7011 boundary condition inflow. 

beta_bc(:) = 0.0 

When subsonic_inf low_velocity = ’ alpha, beta’ , this is the angle 
of sideslip in radians for 7011 boundary condition inflow. 

thetal(:) = 0.0 

When subsonic_inf low_velocity = ’interior’ or ’offset’, this is 
the Euler angle 6 in radians for 7011 boundary condition inflow. 

theta2(:) = 0.0 

When subsonic_inf low_velocity = ’interior’ or ’offset’, this is 
the Euler angle (j) in radians for 7011 boundary condition inflow. 
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theta3(:) = 0.0 

When subsonic_inf low_velocity = ’ interior’ or 'offset’, this is 
the Euler angle if} in radians for 7011 boundary condition inflow. 

pt_amplitude ( : ) = 0.0 

For use with the 7011 boundary condition, this sets the amplitude of 
pulsed total pressure. ampl*sin(freq*simulation_time+phase*pi/180). 

pt_frequency ( : ) = 0.0 

For use with the 7011 boundary condition, this sets the frequency of 
pulsed total pressure, see ampl. 

pt_phase(:) = 0.0 

For use with the 7011 boundary condition, this sets a phase shift (in 
degrees) of the inflow total pressure values, see ampl. 

tt_amplitude( : ) = 0.0 

For use with the 7011 boundary condition, this sets the amplitude of 
pulsed total temperature conditions. 

tt_frequency ( : ) = 0.0 

For use with the 7103 boundary condition, this sets the frequency of 
pulsed total temperature, see ampl. 

tt_phase(:) = 0.0 

For use with the 7011 boundary condition, this sets a phase shift (in 
degrees) of the inflow total temperature, see ampl. 

ampl(:) = 0.0 

For use with the 7103 boundary condition, this sets the amplitude of 
pulsed inflow conditions. Only the velocity is varied using the equation 
\u,v,w] = ampl*sin(freq*simulation_time+phase*pi/180). 

freq(:) = 0.0 

For use with the 7103 boundary condition, this sets the frequency of 
pulsed inflow velocity values, see ampl. 

phase(:) = 0.0 

For use with the 7103 boundary condition, this sets a phase shift (in 
degrees) of the inflow velocity values, see ampl. 
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random(:) = .false. 

For use with the 7103 boundary condition, this creates random fluctua- 
tions in in the magnitude of the supersonic inflow conditions in the range 
[0,ampl] when .true.. 

ramp.constant ( : ) = 1.0 

For use with 7104 boundary condition, this ramps the velocity magnitude 
of supersonic inflow conditions with the exponential expression, (1 — 
exp(— simulation_time/ramp_constant)). 

pressure_relaxation( : ) = 1.0 

For use with the 5051 boundary condition, this weights the user specified 
back pressure with the solution pressure. p -applied = pressure-relaxation 
* static_pressure_ratio + ( 1 - pressure-relaxation ) * pressure-internal 

nozzle_symmetry = 1.0 

Use this factor to scale the area and massflow of a nozzle face. For 
example, set to 2.0 to double a nozzle face on a symmetry plane or set 
to 1.0 for a full span model. 

inlet_symmetry = 1.0 

Use this factor to scale the area and massflow of an inlet face For example, 
set to 2.0 to double an inlet face on a symmetry plane or set to 1.0 for 
a full span model. 

npr_set = 0.0 

This sets the nozzle pressure ratio for nozzle component performance. 

massf low_set_in = 0.0 

For use with 7036 boundary condition, this is the massflow into the 
computational domain in the units of grid squared. Inflow Mach number 
must be less than one. 

static_pressure_ratio( : ) = 1.0 

This is the ratio of specified boundary static pressure to reference pres- 
sure used by the 7012 and 5051 boundary conditions. Outflow Mach 
number must be less than one. 

inlet_solutionunethod( : ) = , mach ) 

This is the solution method for 7031 be. 

‘ maclU adjusts back pressure to attain a Mach number raach_bc. Do not 
use for a face that has boundary layer ingestion; use ’ pressure 5 in that 
situation. 
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‘ raassf lux ; adjusts back pressure to attain a specified mass flux massf low. 
‘ pressure ’ adjusts back pressure to attain a specified mass flux massf low. 

mach_bc(:) = 0.0 

This is Mach number on boundary face used by 5052 and 7031 boundary 
conditions. Outflow Mach number must be less than one. 

massflow(:) = 0.0 

This is massflow through boundary face in units of grid unit squared 
used by 7031 and 7036 boundary conditions, ft is nondimensionalized 

according to (p/Poo ) ('ll/ Woo ) -^-boundary condition- 

massf low_set_out = 0.0 

For use with 7031 boundary condition, This is massflow out of the com- 
putational domain in units of grid squared. Outflow Mach number must 
be less than one. 

massf low.dimensions = ’ nondinF 

This is used for converting a user specified dimensional massflow to units 
of mesh units squared. 

< nondim J for nondimensional massflow input (units of mesh squared) 
‘english’ for Ibrn/s 
‘ metric J for kg/s 

grid units = ’ nondim’ 

This converts a user specified dimensional massflow to units of mesh unit 
squared. If massflow is input in units of mesh units squared, grid_units 
is not required. 

< nondim J for nondimensional input 

‘ m J for meters 

‘ cm ’ for centimeters 

‘ mm ’ for millimeters 

'feet’ for feet 

‘ inches J for inches 

q_set ( : , 1 : 5) = 0.0 

This sets the primitive variables on boundary face used by boundary 
conditions 7100 and 7105. 
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q_set_ramp( : ) = 0 

When this is greater than zero, primitive variables on boundary face are 
ramped from zero to q_set over these iterations, for boundary conditions 
7100 and 7105. 

prof ile_type ( : ) = ’ radial .polynomial J 
This switches between inflow profiles, 

‘ radial.polynomial ’ defines a radial polynomial about patch.center 

of size patch_scale with prof ile_rho_coef , prof ile_u_coef , and prof ile_p_coef . 

‘ power_law’ defines a power-law velocity profile function with prof ile_coef . 

patch_center ( : , 1 : 3) = 0.0 
This is the center of a 7101 be. 
patch_scale( : ) = 1.0 
This scales the radius of a 7101 be. 
prof ile_rho_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of density for 7101 be. 
prof ile_u_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of u for 7101 be. 
prof ile_p_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of pressure for 7101 be. 
prof ile_coef ( : , 1 : 3) = 0.0 

These three coefficients are wind speed reference, reference height, and 
power law exponent, 

prof ile_coef ( : , 1) * (z/prof ile.coef ( : , 2) ) **prof ile_coef ( : , 3) 
wall_velocity( : , 1 : 3) = 0.0 

This is the 4000 solid wall specified translational velocity. It should be 
tangent to the boundary to ensure a well-posed problem. 

rotation.center ( : , 1 : 3) = 0.0 

This is the 4000 solid wall specified rotational velocity center point, see 
rotation.vector and rotation_rate. 

rotation.vector ( : , 1 : 3) = 0.0 

This is the 4000 solid wall specified rotational vector, see rotation_center 
and rotation_rate. Should be unit length. 
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rotation_rate( : ) = 0.0 

This is the 4000 solid wall specified rotational rate, see rotation.center 
and rotation.vector 

unorm_bc(:) = 0.0 

This is the specified velocity in the boundary normal direction, for 4000 
solid walls. 

wall_temperature( : ) = 1.0 

This is the ratio of wall temperature to reference temperature for eqn.type 
= ’ compressible ’ or the wall temperature in degrees Kelvin for eqn.type 
= 'generic 5 . If set to -1, then the wall temperature is computed so 
that there is zero heat flux, i.e., adiabatic. The wall_temp_f lag must 
be set to .true, for this boundary condition to take effect. 

wall_temp_f lag( : ) = .false. 

This must be .true, when specifying the wall temperature via the namelist 
variable wall_temperature. The default .false, sets = 1+ 
for eqnrtype = 'compressible', see Anderson and Bonhaus [2], 

wall_radeq_f lag( : ) = .false. 

Compute the wall temperature via the Stefan-Boltzmann Law. The ra- 
diative equilibrium wall temperature is computed from the heating rate 
Qwaii using q wa u = eaT^ adeq where the surface cmissivity e is entered as 
wall.emissivity and a is the Stefan-Boltzmann constant. 

wall.emissivity ( : ) = 0.8 

This is Co, where emissivity is specified as a function of wall temperature 
with the expression e = e 0 + T(e& + T(e c + Tea))- The other coefficients 
are entered via the following three variables. 

wall_emissivity_b( : ) = 0. 

This is 6b in the above equation. 

wall_emissivity_c ( : ) = 0. 

This is e c in the above equation. 

wall_emissivity_d( : ) = 0. 

This is e,i in the above equation. 

wall.temp .relax ( : ) = 0.001 

This is the relaxation factor r) used for wall_radeq_f lag wall tempera- 
ture boundary condition. The wall temperature is updated as T new = 
T old + V *(T radeq -T old ) 
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wall_catalysis_model ( : ) = ’ super-catalytic 5 

This defines the catalytic efficiency of the wall to promote recombination 
of atoms to molecules. Allowable options are: 

‘ super-catalytic ’ Forces the mass fraction of species at the wall to 
equal the mass fractions specified for the free stream in the tdata file. 

‘ fully-catalytic ’ Specifies a catalytic efficiency of 1 thereby forcing 
homogeneous recombination of atoms diffusing to the wall. 

‘ non-catalytic ’ Specifies a zero mole fraction gradient at the wall - 
signifying zero catalytic efficiency. 

‘ equilibrium-catalytic ’ Computes the equilibrium chemical compo- 
sition of species at the wall temperature and pressure. 

‘ constant-catalytic ’ Catalytic efficiency is user specified constants 

‘ Stewart-RCG’ Reaction cured glass from Stewart 

< Zoby-RCG ) Reaction cured glass from Zoby 

‘Scott-RCG’ Reaction cured glass from Scott 

‘CSiC’ Experimental CSiC from JSC for X-38 

‘ RCC-LVP ’ Stewart NASA TM 112206 

‘CCAT-ACC’ Shuttle RCC from Stewart NASA TM 112206 

‘ CSiC-SNECMA’ Derived from Stewart RCC 

catalytic_ef f iciency_o ( : ) = 0. 

This is the fraction of diffusion flux of atomic oxygen striking wall 
that is converted to molecular oxygen, when wall_catalysis_model = 
’ constant-catalytic ’ . 

catalytic.ef f iciency_n( : ) = 0. 

This is the fraction of diffusion flux of atomic nitrogen striking wall 
that is converted to molecular nitrogen, when wall_catalysis unodel = 
’ constant-catalytic ’ . 

ablation_option_map( : ) = 0 

This is an integer that specifies whether the pyrolysis ablation rate and 
wall temperature are computed in addition to the char ablation rate. 
This option only affects cases with bprime_f lagunap equal to 0 or 1. 

‘ 0 J The pyrolysis ablation rate and wall temperature are computed, in 
addition to the char ablation rate, assuming steady-state ablation. 

‘ 1 J The pyrolysis ablation rate and wall temperature are held constant 
(they are set to the values present in ablation.f rom_laura.m) while the 
char ablation rate is computed. 
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steady .ablation = .false. 

This flags triggers the surface deformation and mesh movement through 
aeroclastic deformation. Note: this flags only applies to the internal 
Fun3D coupled-ablation mechanism and is not applicable to Fun3d- 
CHAR coupled ablation. Default: .false. 

ablation_recession_freq = 3000 

It is an integer that specifies the frequency of surface recession update. 
This flags only works with steady .ablation = .true.. Default: 3000 

start_recession = 0 

It is an integer that specifies when to start applying recession for surface 
deformation. Default: 0 

bprime_f lag_map( : ) = 1 

This is an integer defining if the b-prime approach is applied. Applicable 
only for blowing model equil.char.quasi.steady = 0. 

‘ 0 J Do not use bprime approach, and instead use a rigorous diffusion 
model. This option is consistent with the ’’Fully-Coupled” approach 
defined in Ref. [2], 

‘ 1 ’ Use b-prime approach. This option is consistent with the ’’Partially- 
Coupled” approach defined in Ref. [2], 

‘ 2 J Hold the ablation rate and wall temperature constant from the 
restart file, while applying the rigorous diffusion model (thus, the surface 
energy balance and char equilibrium constraint are not satisfied). This 
option is sometimes useful when transitioning from a bprime flag = 1 
computation to a bprime flag = 0 computation. 

computeundot.initialunapC : ) = 1 

This is an integer defining if the ablation rates are computed before the 
first flowfield iteration. 

‘ 0 ’ Applies the ablation rates and wall temperatures present in the 

ablation.f rom.laura.m file. 

‘ 1 ’ Computes the ablation rates and wall temperatures before the first 
flowfield iteration. 

frequndot unap( : ) = 5000 

For bprime_f lagunap = 1, this is an integer defining frequency of up- 
dating ablation rates and wall temperature. 
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freq_wall_map( : ) = 50 

For bprime_flag = 1, this is an integer defining frequency of update 
to ablation wall boundary conditions. For bprime_flag = 0, an inte- 
ger defining frequency of update to the surface energy balance solution, 
which defines the wall temperature. 

uncoupled_ablation_flag_map( : ) = 0 

This is an integer defining if an uncoupled ablation analysis is applied. 
The uncoupled ablation option is included to provide a baseline solution 
for the coupled ablation analysis. 

‘ 0 J Do not apply an uncoupled ablation analysis. 

‘ 1 J Apply an uncoupled ablation analysis to a converged non-ablating 
flowfield. 

wallJblowingnnodeK : ) = ’none’ 

This is the blowing or ablation model. 

‘ none ’ No wall blowing 

‘ specif ied’ blowing rate is user specified function of pressure (see also 
mdot.press) 

‘ porous_chamber 5 Special options for simulation of buoyancy driven 
flow in pressurized rig for BNNT production 

‘ quasi.steady ’ Compute ablation rate as function of surface energy 
balance and equilibrium catalytic be 

‘ equil_char_quasi_steady ’ Include equilibrium char approximation 
'FIAT’ Couple to material response code FIAT (not active) 
virgin_density_wall ( : ) = 1. 

This is the density (kg/m 3 ) of thermal protection system ablator in virgin 
state (prior to heating level sufficient to cause any reactions). 

char_density_wall ( : ) = 1. 

This is the density (kg/m 3 ) of remaining char in ablator after binding 
resins have pyrolized. 

CHONSi_frac_char_map( : , 1) = 1. 

See definition below for CH0NSi_f rac_pyrolysis_map 

CHONSi_frac_pyrolysis_map( : , 1) = 1. 

These arrays set elemental mass fraction (second index) of C, H, O, N, 
Si, Fe, Mg, Na, B species for char and pyrolysis gas. The fractions in 
each array should sum to 1. 
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h_ablation_map( : , : ) = 0. 

This is a vector of extent 3 used to compute the heat of ablation in M J /kg 
for quasi steady blowing option as h_ablation_0(l) + (h_ablation_0 (2) 

) log pw + (h_ablation_0 (3) ) (log pw) * *2 where pw is the local 
pressure, in atmospheres. 

indot _pressure_map( ) = 0. 

This is a vector of extent 2 is used to set the blowing or suction dis- 
tribution defined as mdot_pressure_0(l) + (mdot_pressure_0(2))*p/ 
(rho.inf *V_inf **2) where p is the local pressure, rho_inf is the refer- 
ence density, and V_inf is the reference velocity. Positive value produces 
blowing distribution, while negative value produces suction distribution. 

t_sublimation_map( : , : ) = 0. 

This is a vector of extent 3 used to compute the sublimation temperature 
in degrees Kelvin for quasi steady blowing option as t_sublimation_0 (1) 

+ (t_sublimation_0(2) ) log pw + (t_sublimation_0 (3) ) (log pw) 
**2 where pw is the local pressure, in atmospheres. 

plenum_t0( : ) = 1000. 

For use with the 7021 boundary condition, this is the total plenum tem- 
perature in Kelvin. 

plenum_p0( : ) = 1000. 

For use with the 7021 boundary condition, The total plenum pressure in 
N/m 2 (Pascals) feeding this boundary. 

plenum_id( : ) = 0 

For use with the 7021 boundary condition (one or more rcs.jet plenum 
bcs), the jet plenum contains this species set from the hie tdata. For 
example, if an RCS jet is bring H 2 and O 2 into an air stream, the tdata 
hie may look like: 

One Temperature 
N 
0 

N2 0.76 
02 0.24 
NO 

H2 0.5 
02 0.5 
OH 
H 
0 
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In this case, if the boundary to the plenum is surface number 5 then 
plenum_id(5)=2, the second grouping of species in the tdata file. The 
numbers following the species name define the mass fraction of that 
species at the inflow boundary. The sum of the mass fraction in each 
group must equal one. Species groups are separated by blank lines and 
multiple RCS jets may be defined in this manner. 

f ixed_in_id( : ) = 0 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the supersonic inflow boundary condition contains the species 
set in the same way as the plenum_id for the rcs.jet plenum boundary 
condition described above 

f ixed_in_rho ( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the dimensional inflow mixture density in kg/m* *3 

f ixed_in_uvw( : , 1 : 3) = 0. 

For use with the 70XX boundary condition (one or more supersonic in- 
flow bcs) the dimensional inflow Cartesian velocity components in m/sec 

f ixed_in_t ( : ) = 0, 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the dimensional inflow translational rotational temperature 
in Kelvin 

f ixed_in_tv( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the dimensional inflow vibrational-electronic temperature in 
Kelvin 

f ixed_in_turb( : , 1 : 7) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) This is for the turbulence models for a one-equation model 
this is the ratio of the inflow eddy viscosity to the inflow molecular 
viscosity, for a two-equation model this is: the inflow turbulence intensity 
and the ratio of the inflow eddy viscosity to the inflow molecular viscosity 
Full Reynolds stress models are not currently supported 

specif ied_transition( : ) = .false. 

When .true., a turbulent transition point will be imposed on the solu- 
tion. 
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irapose_pressure_gradient = .false. 

When .true., a global pressure gradient in the x-direction of pressure.gradient 
will be imposed as a source term to the residual. 

pressure.gradient = 0.0 

The nondimensional pressure gradient in the x-direction, imposed when 
impose_pressure_gradient = .true. 

solidity(:) = 0.0 

This is the percent solidity to be applied to the passive porosity boundary 
conditions. 

porous.coef f icient ( : ) = 0.0 

This is the Darcy law equation coefficient. 

x_c onst ant .boundary (: ) = .false. 

This specifies that a boundary is an x constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
x-symmetry boundaries. 

y.constant.boundary ( : ) = .false. 

This specifies that a boundary is an y constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
y-symmetry boundaries. 

z_constant_boundary ( : ) = .false. 

This specifies that a boundary is an z constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
x-symmetry boundaries. 

tol.const.coord = 1.0e-6 

This is the tolerance for verifying that a boundary surface is a planar 
boundary for mesh movement by restricting the minimum and maximum 
value in the “constant” direction. 
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B.4.17 fetwo d trans 

This namelist is used to specify a 2D transition location. If the airfoil is split 
into upper and lower patches, the transition location can be specified indepen- 
dently on each patch. If there is only a single patch, it can be split with a z 
value to designate the upper and lower airfoil surfaces. This transition specifi- 
cation is limited to specifying transition on a single-element configuration such 
as an airfoil or a flat plate. Only a single transition location is supported for 
multi-element airfoils. Transition is modeled by turning off the turbulent pro- 
duction terms in “laminar” regions of the grid. This option is only valid for the 
perfect gas SA turbulence model. This is the same approach taken in CFL3D 
and NSU3 D.Fun 3D results from this approach for a DLR-F6 transonic cruise 
condition are shown in Lee-Rausch et al. [46] 

&two_d_trans 

turb_transition 
use_2d_values 
upper_patch 
lower_patch 
use_z_value 
z_location 
upper _x_lo cat ion 
lower_x_location 

/ 

turb_transition = .false. 

This must be .true, to specify laminar regions of flow during a turbulent 

flow simulation. 

use_2d_values = .false. 

This enables 2D transition specification. 

upper _patch = 1 

This is the upper patch with specified transition. 

lower_patch = 1 

This is the lower patch with specified transition. 

use_z_value = .false. 

This allows a single patch to be split into upper and lower surfaces of an 

airfoil by a z plane. 

z_location = 0.0 

This is the z location to split the airfoil if use_z_value = .true. 


= .false. 
= .false. 
= 1 
= 1 

= .false. 
= 0.0 
= 0.0 
= 0.0 
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upper_x_location = 0.0 

This is the upper surface x transition location. 

lower_x_location = 0.0 

This is the lower surface x transition location. 
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B.4.18 &three d trans 

This namelist is used to specify 3D boundary layer transition locations. The 
command line option — turb.transition is required to activate. If you run 
the flow solver without the — turb.transition, it will default to fully tur- 
bulent even though you have the laminar boundaries defined. Transition is 
modeled by the turning off the turbulent production terms in “laminar” re- 
gions of the grid. This option is only valid for the perfect gas SA turbulence 
model. This is the same approach taken in CFL3D and NSU3 D.Fun 3D re- 
sults from this approach for a DLR-F6 transonic cruise condition are shown 
in Lee- Rausch et al. [46] 

&three_d_trans 
use_3d_values 
n_transition_group 
transition_group_patches ( : ) 
transition_xl ( : ) 
transition_yl ( : ) 
transition_x2 ( : ) 
transition_y2 ( : ) 

/ 

use_3d_values = .false. 

This turns 3D transition specification on. 
n_transition_group = 1 

This is the number of patch groups, limited to 100. 
transition_group_patches ( : ) = ’ 1 ’ 

This is the patch indexes for each group. Commas and dashes can be 
used to specify ranges, i.e., ’1,2, 5-7 ’ . 

transitionxxl ( : ) = 0.0 

This is the x value for determining the start of the transition line. 
transition_yl ( : ) = 0.0 

This is the y value for determining the start of the transition line. 
transition_x2( : ) = 0.0 

This is the x value for determining the end of the transition line. 
transition_y2( : ) = 1.0 

This is the y value for determining the end of the transition line. 


= .false. 
= 1 
= ' 1 ' 

= 0.0 
= 0.0 
= 0.0 
= 1.0 
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B.4.19 feflow initialization 

This namelist allows the user to initialize regions of the meanflow solution with 
quantities other than freestream. A maximum of 100 volumes can be defined. 
The volumes may overlap each other as well as domain boundaries. In the event 
that a grid point is contained in more than one volume, a subsequent volume 
in this hie will supersede the volumes listed before it. Boundary conditions 
supersede the how initialization. 


&flow_ initialization 


number _of_volumes 

= 

0 

type_of _volume ( : ) 

= 

1 none 1 

center(l :3, : ) 

= 

0.0 

radius ( : ) 

= 

0.0 

pointl (1 : 3 , : ) 

= 

0.0 

point2 (1 : 3 , : ) 

= 

0.0 

radius 1 ( : ) 

= 

0.0 

radius2( : ) 

= 

0.0 

rho ( : ) 

= 

1.0 

c ( : ) 

= 

1.0 

u( : ) 

= 

0.0 

v( : ) 

= 

0.0 

w( : ) 

= 

0.0 

mass_f raction( : , : ) 

= 

l.e-20 

temperature ( : , : ) 

= 

1000. 


/ 

number_of ..volumes = 0 

This is the number of initialization volumes. 

type_of wolume ( : ) = ’none’ 

This is the type of initialization volume. 

'box’ for a box. The diagonal corners are specihed by point 1 and 
point2. 

‘ sphere ’ for a sphere. The position and size is specihed by center and 
radius. 

'cylinder’ for a cylinder with size radius. The center axis is defined 
between pointl and point 2. 

' cone ’ for a cone or frustum. The center axis is defined between pointl 
and point2. Two radii are required, radius 1 at pointl and radius2 
at point2. A frustum is specihed with two nonzero radii. 

center(l : 3, : ) = 0.0 

This is the center of the ’ sphere ’ volume type. 
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radius(:) = 0.0 


This is the radius of the ’ sphere’ and ’ cylinder’ volume types, 
pointl (1 : 3, : ) = 0.0 

This is one end of the ’ cone ’ or ’ cylinder’ volume types or one corner 
of a ’box’ volume type. 

point2(l : 3, : ) = 0.0 

This is the other end of the ’ cone’ or ’ cylinder’ volume types or the 
opposite corner of a ’box’ volume type. 

radiusl(:) = 0.0 

This is the radius at pointl of ’ cone’ volume type. 
radius2(:) = 0.0 

This is the radius at point2 of ’ cone’ volume type. 
rho(:) = 1.0 

This is the nondimensional density in the volume. 
c ( : ) = 1.0 

This is the nondimensional speed of sound in the volume. 
u( : ) = 0.0 

This is the nondimensional ^-component of velocity in the volume. 
v( : ) = 0.0 

This is the nondimensional ^-component of velocity in the volume. 

w( : ) = 0.0 

This is the nondimensional ^-component of velocity in the volume. 
mass_fraction( : , : ) = l.e-20 

This is the species mass fraction array in the volume. The maximum 
number of species is hardwired to 50 in this namelist. All mass fractions 
are initialized to trace values (l.e-20) so it is only necessary to define 
non-trace species. 

temperature ( : , : ) = 1000. 

This is the translational-rotational and vibrational electronic tempera- 
ture array in the volume, in units of Kelvin. 
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B.4.20 fecomponent parameters 

This namelist provides expanded ability to track forces, moments, and mass- 
flows according to user-specified groups of boundary patches that define a 
“component.” 

&component .parameters 
number_of_ components 
component_count ( : ) 
component_xmc ( : ) 
component_ymc ( : ) 
component_zmc ( : ) 
component_cref ( : ) 
component_bref ( : ) 
component_sref ( : ) 
component_hinge_sweep( : ) 
component_hinge_dihedral ( : ) 
component_input ( : ) 
component_name ( : ) 
calculate_cd( : ) 
calculate_thrust_ratio( : ) 
massf low_component ( : ) 
throat_area( : ) 
units ( : ) 
npr ( : ) 

allow_f low_through_f orces 

/ 

number _of .components = 0 
This is the number of components (groups of boundary patches) to track, 
component .count ( : ) =0 

This is the number of boundary patches assigned to a component. If -1 
is given, this number is computed implicitly from component.input. 

component_xmc( : ) = xunoment.center 

This is ^-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce jnoment.integ.properties 

component_ymc( : ) = y_moment_center 

This is ^/-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orceunoment.integ.properties 

component_zmc( : ) = z_moment_center 

This is z-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce .moment.integ.properties 


= 0 
= 0 

= x_moment_ center 
= y_moment_ center 
= z_moment_center 
= x_moment_ length 
= y .moment. length 
= ref erence.area 
= 0.0 

= 0.0 
_ I I 

_ I I 

= .false. 

= .false. 

= 0 

= 0.0 
_ I I 

= 0.0 
= .false. 
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component _cref ( : ) = x_moment_length 

This is the ^-direction reference length assigned to a component used to 
non-dimensionalize moments about y (pitching moment). The default 
value comes from the force and moment namelist &f orce_moment_integ_properties. 

component _bref ( : ) = y_moment_length 

This is the ^/-direction reference length assigned to a component used to 
non-dimensionalize moments about x (rolling moment) and z (yawing 
moment). The default value comes from the force and moment namelist 
&f orce unoment_integ_properties. 

component.sref ( : ) = ref erence_area 

This is the reference area assigned to a component used to non-dimensionalize 
forces and moments. The default value comes from the force and moment 
namelist &f orce_moment_integ_properties. 

component _hinge_sweep( : ) = 0.0 

This is the hinge sweep angle in degrees assigned to a component used 
to non-dimensionalize moments about y (pitching moment). The default 
value is zero. 

component_hinge_dihedral ( : ) = 0.0 

This is the hinge dihedral angle in degrees assigned to a component used 
to non-dimensionalize moments about x (rolling moment). The default 
value is zero. 

component _input ( : ) = ’ ’ 

This is the list of boundary patches to assigned to a component. Bound- 
ary indexes are separated with commas and dashes can be used to specify 
ranges, i.e., ’1,2, 5-7’. 

component _name ( : ) = 1 ’ 

This is the component output filename, [pro j ect_rootname] _fm_ [component mame] 
.dat. 

calculate_cd( : ) = .false. 

This will request an ideal mass flow calculation for component n. 
calculate_thrust_ratio ( : ) = .false. 

This will request a thrust ratio calculation for component n. 
massf low.component ( : ) = 0 

Specifies what component to get the physical mass flow from to calculate 
the ideal thrust. 
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throat_area( : ) = 0.0 

This is the throat area associated with component n. 

units ( : ) = ’ ’ 

This is the units of the throat area specified. 

npr(:) = 0.0 

This is the set nozzle pressure ratio associated with component n. 

allow_f low_through_f orces = .false. 

Pressure drag and skin friction forces are by default calculated only on 
boundary faces designated as solid surfaces ( viscous or inviscid ). To 
include the pressure and momentum flux forces due to nozzles or in- 
lets allow_f low_through_f orces should be set to .true.. The flow- 
through faces to be tracked should be listed in the component_count 
and component.input lists accordingly. 
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B.4.21 &time avg params 


This namelist controls the bookkeeping of time average and root mean square 
statistics for every point in the domain. Tracking these statistics enables vi- 
sualization of variables like p_tavg, u_trms, etc. See the visualization output 
variable namelists &volume_output_variables, &boundary_output_variables, 
and &sampling_output_variables for details. When these statistics are tracked, 
the hie [project_rootname] _TAVG.l maintains information across restarts. 
This statistics hie is similar to the [project_rootname] .flow restart hie in 
that is not intended for the user to interact with directly. 


&time_avg_params 

itime_avg = 0 

prior_time_avg = 0 

use_prior_time_avg = 0 
tavg_header_version = 1 

/ 


itime_avg = 0 

This controls collection of statistics. 

‘ 0 J does not compute time averaging statistics. 

‘ 1 J computes time averaging statistics. 

prior_time_avg = 0 

This option specihes if a statistics hie [project_rootname] _TAVG.l ex- 
ists. 

‘ 0 J when no time averaging hie exists. 

‘ 1 J when time averaging hie from previous run exists. 
use_prior_time_avg = 0 
if available, use prior statistics. 

‘ 0 J for discarding the prior statistics. 

‘ 1 J for using and appending to the prior statistics. 
tavg_header_version = 1 

This option controls the variables for which statistics are collected. 

‘ 1 ’ primitive variable averages and root mean squares 

‘ 2 J primitive variable averages and root mean squares and the averages 

of u’ v J , u ’ w ’ , v ’ w ’ , rau_t , vort unag. 
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B.4.22 &:global 


This namelist controls the frequency of visualization output and the logging of 
command line options. It also serves to control some global options otherwise 
set by command- line input 

&global 

moving_grid 
grid_motion_only 
grid_motion_and_dci_only 
body_motion_only 
timing 

time_moving_grid 
boundary_animation_freq 
volume_animation_f req 
slice_f req 

record_command_lines 

/ 

moving.grid = .false. 

This governs whether the grid is moving or stationary 
gridunotion_only = .false. 

This turns off the flow solve during a simulation for which moving_grid = 
.true.. If the simulation involves overset grids, this command overrides 
dci_on_the_f ly and DCI hies are not output. 

gridunotion_and_dci_only = .false. 

This turns off the how solve during a simulation for which moving.grid 
= .true.. If the simulation involves overset grids, this command honors 
dci_on_the_f ly and DCI hies are output if dci_on_the_f ly = .true.. 

body_motion_only = .false. 

This turns oh both the how solve and the linear elasticity solve dur- 
ing a simulation for which moving.grid = .true, and gridunotion = 
’ deform ’ 

timing = .false. 

This triggers a timing of the execution of various sections of the how 
solver. 

time_moving_grid = .false. 

This triggers timing of the execution of various sections of the how solver, 
with emphasis on operations associated with grid motion. The timing 
occurs over larger sections of the code than the timing option. For 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= 0 
= 0 
= 0 

= .false. 
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correct timing information, timing and timeanoving_grid should not 
be used simultaneously. 

boundary_animation_freq = 0 

This is the visualization output frequency of the domain boundaries. 

Zero is no output, -1 is output at the end of run, and a positive integer 
is periodic output every boundary_animation_freq iterations. See the 
&boundary_output_variables namelist for more details. 

volume_animation_f req = 0 

This is the visualization output frequency of the domain volume. Zero 
is no output, - 1 is output at the end of run, and a positive integer is peri- 
odic output every volume_animation_f req iterations. See &volume_output_variables 
namelist for more details. 

slice_freq = 0 

This is the output frequency of boundary slices for visualization and to 
obtain loads. Zero is no output, -1 is output at the end of run, and 
a positive integer is periodic output every slice_freq iterations. See 
&slice_data namelist for more details. 

record_command_lines = .false. 

This creates a hie temp. commands that contains the command line argu- 
ments 
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B.4.23 fcvolume output variables 

This namelist controls volume variable output. Output frequency is controlled 
by volume_animation_f req in the &global namelist. The resulting volume- 
data hies have the following naming convention for export_to= ) tecplot ’ 
output: 

[project_rootname] _part [P] _tec_volume_timestep [T] ( . dat | .pit) if freq > 0 
[project_rootname] _Part [P] _tec_volume( .dat | .pit) if freq < 0 

where P = 1,2,. . . ,nproc (number of processors) and T is the iteration number. 

The hie extension is .dat for ASCII Tecplot™ format and .pit for binary 
Tecplot™ format. Within the hies, a single zone is written, with the zone 
title “time 0.0000000E+00 processor 32” where the time value is the integer 
iteration number for steady-state cases, and the current (non-dimensional) 
time for time-dependent cases. 

A request to output an undefined variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 


&volume_output_variables 


export_to 

= 

' tecplot 

X 

= 

. true . 

y 

= 

. true . 

z 

= 

. true . 

primitive_variables 

= 

. true . 

rho 

= 

.false . 

u 

= 

.false . 

V 

= 

.false . 

w 

= 

.false . 

P 

= 

.false . 

entropy 

= 

.false . 

mach 

= 

.false . 

temperature 

= 

.false . 

iblank 

= 

.false . 

imesh 

= 

.false . 

vort_mag 

= 

.false . 

vort_x 

= 

.false . 

vort_y 

= 

.false . 

vort_z 

= 

.false . 

q_criterion 

= 

.false . 

div_vel 

= 

.false . 

turbulent _f luctuat i ons 

= 

.false . 

uuprime 

= 

.false . 

vvprime 

= 

.false . 

wwprime 

= 

.false . 
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uvprime 

uwprime 

vwprime 

cp 

dp_pinf 

volume 

residuals 

resl 

res2 

res3 

res4 

res5 

res_gcl 

primitive_tavg 

rho_tavg 

u_tavg 

v_tavg 

w_tavg 

P-tavg 

primitive_trms 

rho_trms 

u_trms 

v_trms 

w_trms 

p_trms 

lambdal 

lambda2 

lambda3 

lambda4 

lambda5 

lambda6 

lambda7 

htot 

ttot 

ptot 

etot 

processor_id 

turb_ke 

turb_diss 

mu_t 

turbl 

turb2 

turb3 

turb4 

turb5 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
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turb6 

= 

.false 

turb7 

= 

.false 

turresl 

= 

.false 

turres2 

= 

.false 

turres3 

= 

.false 

turres4 

= 

.false 

turres5 

= 

.false 

turres6 

= 

.false 

turres7 

= 

.false 

slen 

= 

.false 

if lagslen 

= 

.false 

hrles_blend 


.false 

r e construct ion_limiter_phil 

- 

.false 

re construct ion_limiter_phi 2 

= 

.false 

re construct ion_limiter_phi3 

= 

.false 

re construct ion_limiter_phi4 

= 

.false 

re construct ion_limiter_phi 5 

= 

.false 

tt 

= 

.false 

tv 

= 

.false 

sonic 

= 

.false 

mixture_mol_weight 

= 

.false 

mixture_density 

= 

.false 

ev 

= 

.false 

rho_i(l :n_species) 

= 

.false 

mu 

= 

.false 

id_12g 

= 

.false 

divided_residuals 

= 

.false 


export.to = ; tecplot’ 
file format of volume export 

'tecplot' is Tecplot™ format (one file written for each processor) 

‘ cgns ’ is CGNS format, requires Fun3D to be configured with a CGNS 
library. This format already includes x, y, and z. Set these variables to 
.false, to avoid duplication. 

‘fvuns’ is FieldView C-binary (Fortran stream) format. This format 
already includes x, y, and z. Set these variables to .false, to avoid 
duplication. 

‘fv’ is depreciated. Slated for removal, use ’fvuns’ 

'vtk’ is legacy VTK format This format already includes x, y, and z. 
Set these variables to .false, to avoid duplication. 

‘ csv’ is comma separated value format 
‘ sol 1 is INRIA Metrix sol format 
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'tec’ is a single image ASCII Tecplot™ format 

'raw.ascii’ is a single image ASCII space separated format 

' native ’ is the most efficient way to export the entire flow field to disk 
at every time step when the grid is over a billion elements, but requires 
specialized visualization tools to read. 

x = .true. 

X-coordinate 
y = .true. 

Y -coordinate 
z = .true. 

Z-coordinate 

primitive.variables = .true. 

Output primitive variables: rho, u, v, w, and p 
rho = .false. 

Density 
u = .false. 

X-component of velocity 

v = .false. 

X-component of velocity 
w = .false. 

Z-component of velocity 
p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 
temperature = .false. 

Temperature 
iblank = .false. 

I-blanking variable (default becomes .true, for overset mesh cases) 


163 



imesh = .false. 


For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortanag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-component of vorticity 

vort_y = .false. 

Y -component of vorticity 

vort_z = .false. 

Z-component of vorticity 

q.criterion = .false. 

Q Criterion, the second invariant of W 

div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprime turbulent shear stresses normalized by 
■u^e/i the dehnition of these variables depends on the turbulence model, 
see http: //turbmodels. larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'u' 

vvprime = .false. 

Turbulence fluctuation, v'v' 

wwprime = .false. 

Turbulence fluctuation, w'w' 

uvprime = .false. 

Turbulence fluctuation, u'v' 

uwprime = .false. 

Turbulence fluctuation, u'w' 

vwprime = .false. 

Turbulence fluctuation, v'w' 
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cp = .false. 

Pressure coefficient 

dp_pinf = .false. 

Normalized delta pressure (p — Poo)/Poo 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, ^-momentum 
res3 = .false. 

Residual of equation 3, ^/-momentum 
res4 = .false. 

Residual of equation 4, ^-momentum 
res5 = .false. 

Residual of equation 5, energy 
res.gcl = .false. 

For moving meshes, residual of grid conservation law 

primitive.tavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rhovtavg, u_tavg, v_tavg, wvtavg, and pvtavg 

rho.tavg = .false. 

Time- averaged density 

u_tavg = .false. 

Time-averaged ^-component of velocity 

v_tavg = .false. 

Time-averaged ^/-component of velocity 
w_tavg = .false. 

Time-averaged ^-component of velocity 
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p_tavg = .false. 

Time- averaged pressure 
primitive.trms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of x- component of velocity 

v_trms = .false. 

RMS-average of ^/-component of velocity 
w_trms = .false. 

RMS-average of ^-component of velocity 

pjtrms = .false. 

RMS-average of pressure 

lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda3 = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda4 = .false. 

Adjoint Lagrange multiplier for equation 4 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda5 = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda6 = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 
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Iambda7 = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor.id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 
turb_diss = .false. 

Turbulence dissipation rate 
mu_t = .false. 

Turbulent eddy viscosity 
turbl = .false. 

Turbulence variable 1 (model dependent) 

turb2 = .false. 

Turbulence variable 2 (model dependent) 

turb3 = .false. 

Turbulence variable 3 (model dependent) 

turb4 = .false. 

Turbulence variable 4 (model dependent) 

turb5 = .false. 

Turbulence variable 5 (model dependent) 

turb6 = .false. 

Turbulence variable 6 (model dependent) 
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turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turres3 = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turres5 = .false. 

Residual of 5th turbulence equation 
turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
slen = .false. 

Length to the nearest solid wall boundary 
iflagslen = .false. 

Turbulence model distance function closest boundary entity, (a negative 
sign indicates the node has been prescribed as laminar) 

hrlesJblend = .false. 

HRLES blending function 

reconstruction_liraiter_phil = .false. 

0 for the node-based reconstruction limiters (equation 1) 

reconstruction_liraiter_phi2 = .false. 

0 for the node-based reconstruction limiters (equation 2) 

reconstruction_liraiter_phi3 = .false. 

0 for the node-based reconstruction limiters (equation 3) 

reconstruction_liraiter_phi4 = .false. 

0 for the node-based reconstruction limiters (equation 4) 
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reconstruction_liraiter_phi5 = .false. 

0 for the node-based reconstruction limiters (equation 5) 

tt = .false. 

Translational temperature only for eqn_type = ’generic’ 
tv = .false. 

Vibrational temperature only for eqnvtype = ’generic’ 
sonic = .false. 

Frozen speed of sound only for eqn_type = ’generic’ 
mixture_mol_weight = .false. 

Mixture molecular weight only for eqn.type = ’generic’ 
mixture_density = .false. 

Mixture density only for eqn.type = ’generic’ 
ev = .false. 

Vibrational energy only for eqn.type = ’generic’ 
rho_i (1 : n_species) = .false. 

Species concentration only for eqn.type = ’generic’ 
mu = .false. 

Total viscosity 
id_12g = .false. 

Local-to-global node map 
divided_residuals = .false. 

adds a _vol suffix to the residual output variable names and divide by 
volume 
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B.4.24 ^boundary output variables 

This namelist controls the boundary variable output. Output frequency is 
controlled by boundary _animation_freq in the &global namelist. By default, 
the output of solution data for all solid surfaces in 3D and on one ^/-constant 
symmetry plane in 2D is included unless boundarydList is specified. 

Each time boundary data output is triggered, all output boundaries are 
written to one hie with the following naming convention: 

[project_rootname] _tec_boundary_timestep [T] ( . dat | .pit) if N > 0 
[project_rootname] _tec_boundary( .dat | .pit) if N < 0 

where T is the iteration number. The hie extension is .dat for ASCII Tec- 
plot lM format and .pit for binary Tecplot M format. Within the hies, each 
boundary is written as a separate zone. The zones are identified with the title 
“time 0.0000000E+00 boundary 5” where the time value is the integer iter- 
ation number for steady-state cases, and the current (non-dimensional) time 
for time-dependent cases. 

By default, output is in the inertial reference frame. For moving body 
problems, the &observer_motion namelist can be used to change the visual- 
ization reference system to a body reference system or a reference system with 
arbitrary motion. 

A request to output an undehned variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 

&boundary_output_variables 


number _of_boundaries 

= 

0 

boundary_list 

= 

i i 

X 

= 

. true . 

y 

= 

. true . 

z 

= 

. true . 

primitive_variables 

= 

. true . 

rho 

= 

. false 

u 

= 

. false 

V 

= 

. false 

w 

= 

. false 

P 

= 

. false 

entropy 

= 

. false 

mach 

= 

. false 

temperature 

= 

. false 

iblank 

= 

. false 

imesh 

= 

. false 

vort_mag 

= 

. false 

vort_x 

= 

. false 

vort_y 

= 

. false 
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vort_z 

= 

. false 

q_criterion 

= 

. false 

div_vel 

= 

. false 

turbulent _f luctuat i ons 

= 

. false 

uuprime 

= 

. false 

vvprime 

= 

. false 

wwprime 

= 

. false 

uvprime 

= 

. false 

uwprime 

= 

. false 

vwprime 

= 

. false 

cp 

= 

. false 

dp_pinf 

= 

. false 

volume 

= 

. false 

residuals 

= 

. false 

resl 

= 

. false 

res2 

= 

. false 

res3 

= 

. false 

res4 

= 

. false 

res5 

= 

. false 

res_gcl 

= 

. false 

primitive_tavg 

= 

. false 

rho_tavg 

= 

. false 

u_tavg 

= 

. false 

v_tavg 

= 

. false 

w_tavg 

= 

. false 

P-tavg 

= 

. false 

primitive_trms 

= 

. false 

rho_trms 

= 

. false 

u_trms 

= 

. false 

v_trms 

= 

. false 

w_trms 

= 

. false 

p_trms 

= 

. false 

lambda 1 

= 

. false 

lambda2 

= 

. false 

lambda3 

= 

. false 

lambda4 

= 

. false 

lambda5 

= 

. false 

lambda6 

= 

. false 

lambda7 

= 

. false 

htot 

= 

. false 

ttot 

= 

. false 

ptot 

= 

. false 

etot 

= 

. false 

processor_id 

= 

. false 

turb_ke 

= 

. false 
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turb_diss 

= 

. false 

mu_t 

= 

. false 

turbl 

= 

. false 

turb2 

= 

. false 

turb3 

= 

. false 

turb4 

= 

. false 

turb5 

= 

. false 

turb6 

= 

. false 

turb7 

= 

. false 

turresl 

= 

. false 

turres2 

= 

. false 

turres3 

= 

. false 

turres4 

= 

. false 

turres5 

= 

. false 

turres6 

= 

. false 

turres7 

= 

. false 

slen 

= 

. false 

tt 

= 

. false 

tv 

= 

. false 

sonic 

= 

. false 

mixture_mol_weight 

= 

. false 

mixture_density 

= 

. false 

ev 

= 

. false 

rho_i(l :n_species) 

= 

. false 

mu 

= 

. false 

id_12g 

= 

. false 

vort_x_rms 

= 

. false 

vort_y_rms 

= 

. false 

vort_z_rms 

= 

. false 

vort_mag_rms 

= 

. false 

vort_mag_tavg 

= 

. false 

yplus 

= 

. false 

mu_t_tavg 

= 

. false 

cmu_star 

= 

. false 

bird_breakdown 

= 

. false 

recovery_temperature 

= 

. false 

turb_mach 

= 

. false 

turbindex 

= 

. false 

average_velocity 

= 

. false 

uavg 

= 

. false 

vavg 

= 

. false 

wavg 

= 

. false 

cf _x 

= 

. false 

0 

l-h 

1 

= 

. false 

0 

l-h 

1 

N 

= 

. false 
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skinfr 

= 

. false 

cq 

= 

. false 

shear_x 

= 

. false 

shear_y 

= 

. false 

shear_z 

= 

. false 

heating 

= 

. false 

mdot 

= 

. false 

utau_wf 

= 

. false 

phi_wf 

= 

. false 

mu_t_wf 

= 

. false 

k_wallfunction_bc 

= 

. false 

omega_wallfunction_bc 


. false 

number_of ^boundaries 



0 


Number of boundary patches given in boundaryLList (if -1 is given, this 
number is computed from boundary.list) 

boundary LList = ’ ’ 

List of boundary patch numbers. Commas and dashes can be used to 
specify ranges, i.e., ’1,2, 5-7 ’ . If nothing is specified, then all but flow- 
through boundaries are output for 3D or a single symmetry plane in 
2D. 

x = .true. 

X-coordinate 
y = .true. 

Y -coordinate 
z = .true. 

Z-coordinate 

primitive.variables = .true. 

Output primitive variables: rho, u, v, w, and p 

rho = .false. 

Density 

u = .false. 

X-component of velocity 

v = .false. 

Y -component of velocity 
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w 


.false. 


Z-component of velocity 

p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 
temperature = .false. 

Temperature 
iblank = .false. 

I-blanking variable (default becomes .true, for overset mesh cases) 

imesh = .false. 

For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortunag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-component of vorticity 

vort_y = .false. 

Y -component of vorticity 

vort_z = .false. 

Z- comp orient of vorticity 

q_criterion = .false. 

Q Criterion, the second invariant of VC 

div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprime turbulent shear stresses normalized by 
uf e j ; the definition of these variables depends on the turbulence model, 
see http: //turbmodels. larc.nasa.gov/noteonrunning.html for details 
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uuprime = .false. 

Turbulence fluctuation, u'u' 
vvprime = .false. 

Turbulence fluctuation, v'v' 
wwprime = .false. 

Turbulence fluctuation, w'w' 
uvprime = .false. 

Turbulence fluctuation, u'v' 
uwprime = .false. 

Turbulence fluctuation, u'w' 
vwprime = .false. 

Turbulence fluctuation, v'w' 
cp = .false. 

Pressure coefficient 
dp_pinf = .false. 

Normalized delta pressure (p — Poo)/Poo 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables. 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, ^-momentum 
res3 = .false. 

Residual of equation 3, ^/-momentum 
res4 = .false. 

Residual of equation 4, ^-momentum 
res5 = .false. 

Residual of equation 5, energy 
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res.gcl = .false. 

For moving meshes, residual of grid conservation law 

primitive.tavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rhovtavg, u_tavg, vvtavg, wvtavg, and pvtavg 

rho.tavg = .false. 

Time- averaged density 

u_tavg = .false. 

Time-averaged ^-component of velocity 

v_tavg = .false. 

Time-averaged ^/-component of velocity 
w_tavg = .false. 

Time-averaged ^-component of velocity 
p_tavg = .false. 

Time- averaged pressure 

primitivejtrms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rhovtrms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of ^-component of velocity 

v_trms = .false. 

RMS-average of ^/-component of velocity 

w_trms = .false. 

RMS-average of ^-component of velocity 

p_trms = .false. 

RMS-average of pressure 

lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 
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Iambda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda3 = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda4 = .false. 

Adjoint Lagrange multiplier for equation 4 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda5 = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda6 = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda7 = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor.id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 
turb_diss = .false. 

Turbulence dissipation rate 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


177 



mu_t = .false. 

Turbulent eddy viscosity 

turbl = .false. 

Turbulence variable 1 (model dependent) 

turb2 = .false. 

Turbulence variable 2 (model dependent) 

turb3 = .false. 

Turbulence variable 3 (model dependent) 

turb4 = .false. 

Turbulence variable 4 (model dependent) 

turb5 = .false. 

Turbulence variable 5 (model dependent) 

turb6 = .false. 

Turbulence variable 6 (model dependent) 

turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turres3 = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turres5 = .false. 

Residual of 5th turbulence equation 
turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
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slen = .false. 

Length to the nearest solid wall boundary 
tt = .false. 

Translational temperature, only for eqn.type = ’generic’ 
tv = .false. 

Vibrational temperature, only for eqn.type = ’generic’ 
sonic = .false. 

Frozen speed of sound, only for eqn.type = ’generic’ 
mixtureunol_weight = .false. 

Mixture molecular weight, only for eqn.type = ’generic’ 
mixture_density = .false. 

Mixture density, only for eqnrtype = ’generic’ 
ev = .false. 

Vibrational energy, only for eqnrtype = ’generic’ 
rho_i (1 : n_species) = .false. 

Species concentration, only for eqn_type = ’generic’ 
mu = .false. 

Total viscosity 
id_12g = .false. 

Local-to-global node map 
vort_x_rms = .false. 

RMS-average of x-component of vorticity 
vort_y_rms = .false. 

RMS-average of ^/-component of vorticity 
vort_z_rms = .false. 

RMS-average of c-component of vorticity 
vortunag_rms = .false. 

RMS-average of vorticity magnitude 
vort unag.tavg = .false. 

Time-average of vorticity magnitude 
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yplus = .false. 

Dimensionless wall distance, y + 
mu_t_tavg = .false. 

Time-average turbulent eddy viscosity 

cmu_star = .false. 

k — e model turbulent length scale parameter 

bird_breakdown = .false. 

Bird continuum breakdown parameter 
recovery.temperature = .false. 

Recovery temperature 
turb_mach = .false. 

Turbulent Mach number 
turbindex = .false. 

Turbulent index 
average_velocity = .false. 

Turns on uavg, vavg, wavg 
uavg = .false. 

X-component of average velocity near a wall (used to plot surface stream- 
lines) 

vavg = .false. 

Y -component of average velocity near a wall (used to plot surface stream- 
lines) 

wavg = .false. 

Z- component of average velocity near a wall (used to plot surface stream- 
lines) 

cf_x = .false. 

X-component of skin friction 
cf_y = .false. 

Y -component of skin friction 
cf_z = .false. 

Z- component of skin friction 
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skinfr = .false. 

Skin friction magnitude with sign determined by the inner product of 
the skin friction vector and the freestream velocity vector 

cq = .false. 

Temperature gradient normal to the wall, with “dimensions” of nondi- 
mensional temperature per unit grid length for eqnvtype = ‘ compressible ’ . 
Heating rate non-dimensionalized by PocV^ for eqn.type = ‘ generic ’ . 

shear_x = .false. 

X-component of shear on the boundary, in MKS units 
shear_y = .false. 

Y -component of shear on the boundary, in MKS units 
shear_z = .false. 

Z-eomponent of shear on the boundary, in MKS units 

heating = .false. 

Heating on the boundary in Watts per centimeter squared (for eqnvtype 
= ‘ compressible ’ , make sure the grid is in meters) 

mdot = .false. 

Dimensionless blowing rate non-dimensionalized by PooPoo 
utau_wf = .false. 

Friction velocity calculated from a wall function model. 
phi_wf = .false. 

Pressure gradient term from a wall function model. 
mu_t_wf = .false. 

Wall function turbulent eddy viscosity at the wall. 
k_wallfunction_bc = .false. 

Turbulent kinetic energy wall function boundary condition. 
omega_wallfunction_bc = .false. 

Omega wall function boundary condition. 


181 



B.4.25 &:sampling output variables 

This namelist controls output of variables from user defined regions of the 
computational domain. To use sampling, the &sampling_parameters namelist 
must be used to define the sampling geometries and the sampling_frequency ( : 

) set for each geometry. 

The resulting sampling data hies will have the following naming convention: 

[project_rootname] _tec_sampling_geom [G] _timestep [T] ( . dat | .pit) if N > 0 
[project_rootname] _tec_sampling_geom[G] ( .dat | .pit) if N < 0 

where G = 1,2,. . . ,number_of .geometries, and T is the iteration number. The 
hie extension is .dat for ASCII Tecplot™ format and .pit for binary Tecplot™ 
format. A global image of the sampling surface is output with the zone title 
“time 0.0000000E+00 geom 3” where the time value is the integer iteration 
number for steady-state cases, and the current (nondimensional) time for time- 
dependent cases. 

A request to output an undefined variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 


&sampling_output_variables 


X 

= 

. true . 

y 

= 

. true . 

z 

= 

. true . 

primitive_ variables 

= 

. true . 

rho 

= 

.false 

rho_i ( : ) 

= 

.false 

u 

= 

.false 

V 

= 

.false 

w 

= 

.false 

p 

= 

.false 

entropy 

= 

.false 

mach 

= 

.false 

temperature 

= 

.false 

tt 

= 

.false 

tv 

= 

.false 

iblank 

= 

.false 

imesh 

= 

.false 

vort_mag 

= 

.false 

vort_x 

= 

.false 

vort_y 

= 

.false 

vort_z 

= 

.false 

q_criterion 

= 

.false 

div_vel 

= 

.false 

turbulent _f luctuat i ons 

= 

.false 
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uuprime 

vvprime 

wwprime 

uvprime 

uwprime 

vwprime 

cp 

dp_pinf 

volume 

residuals 

resl 

res2 

res3 

res4 

res5 

res_gcl 

rho_tavg 

primitive_tavg 

u_tavg 

v_tavg 

w_tavg 

P-tavg 

mu_t_tavg 

vort_mag_tavg 

vort_x_tavg 

vort_y_tavg 

vort_z_tavg 

primitive_trms 

rho_trms 

u_trms 

v_trms 

w_trms 

p_trms 

lambdal 

lambda2 

lambda3 

lambda4 

lambda5 

lambda6 

lambda7 

htot 

ttot 

ptot 

etot 

processor_id 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
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turb_ke 

= 

.false 

turb_diss 

= 

.false 

mu_t_wf 

= 

.false 

mu_t 

= 

.false 

turbl 

= 

.false 

turb2 

= 

.false 

turb3 

= 

.false 

turb4 

= 

.false 

turb5 

= 

.false 

turb6 

= 

.false 

turb7 

= 

.false 

turresl 

= 

.false 

turres2 

= 

.false 

turres3 

= 

.false 

turres4 

= 

.false 

turres5 

= 

.false 

turres6 

= 

.false 

turres7 

= 

.false 

slen 

= 

.false 

if lagslen 

= 

.false 

hrles_blend 

= 

.false 

vort_x_rms 

= 

.false 

vort_y_rms 

= 

.false 

vort_z_rms 

= 

.false 

vort_mag_rms 

= 

.false 

yplus 

= 

.false 

cmu_star 

= 

.false 

mu_t_ratio 

= 

.false 

iib 

= 

.false 

iiib 

= 

.false 

uplus 

= 

.false 

kplus 

= 

.false 

wplus 

= 

.false 

yplusretau 

= 

.false 

tllplus 

= 

.false 

tl2plus 

= 

.false 

tl3plus 

= 

.false 

t22plus 

= 

.false 

t23plus 

= 

.false 

t33plus 

= 

.false 

bird_breakdown 

= 

.false 

vgradrho 

= 

.false 

f _rl 

= 

.false 

xi_k 

= 

.false 

r e construct ion_limiter_phil 

= 

.false 
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reconstruction_limiter_phi2 = .false. 
reconstruction_limiter_phi3 = .false. 
reconstruction_limiter_phi4 = .false. 
reconstruction_limiter_phi5 = .false. 

x = .true. 

X-coordinate 
y = .true. 

Y -coordinate 
z = .true. 

Z-coordinate 

primitive.variables = .true. 

Output primitive variables: rho, u, v, w, and p 

rho = .false. 

Density 

rho_i(:) = .false. 

Species densities 
u = .false. 

X-component of velocity 

v = .false. 

Y -component of velocity 

w = .false. 

Z- comp orient of velocity 
p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 
temperature = .false. 

Temperature 
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tt 


.false. 


Translational-rotational temperature in the generic gas path 

tv = .false. 

Vibrational-electronic temperature in the generic gas path 

iblank = .false. 

I-blanking variable (default becomes .true, for overset mesh cases) 

imesh = .false. 

For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortunag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-cornponent of vorticity 

vort_y = .false. 

Y -component of vorticity 

vort_z = .false. 

Z-component of vorticity 

q_criterion = .false. 

Q Criterion, the second invariant of W 

div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprirae turbulent shear stresses normalized by 
the definition of these variables depends on the turbulence model, 
see http: //turbmodels. larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'v! 
vvprime = .false. 

Turbulence fluctuation, v'v' 
wwprime = .false. 

Turbulence fluctuation, w'w' 
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uvprime = .false. 

Turbulence fluctuation, u'v' 
uwprime = .false. 

Turbulence fluctuation, u'w' 
vwprime = .false. 

Turbulence fluctuation, v'w' 
cp = .false. 

Pressure coefficient 
dp_pinf = .false. 

Normalized delta pressure ( p — Poo)/Poo 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, x-momentum 
res3 = .false. 

Residual of equation 3, y-momentum 
res4 = .false. 

Residual of equation 4, z-momentum 
res5 = .false. 

Residual of equation 5, energy 
res_gcl = .false. 

For moving meshes, residual of grid conservation law 
rho.tavg = .false. 

Time- averaged density 

primitive.tavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rho.tavg, u_tavg, v_tavg, w_tavg, and p_tavg 
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u_tavg = .false. 

Time-averaged x-component of velocity 
v_tavg = .false. 

Time-averaged y-component of velocity 

w_tavg = .false. 

Time-averaged z-component of velocity 
p_tavg = .false. 

Time- averaged pressure 
mu_t_tavg = .false. 

Time-averaged turbulent eddy viscosity 
vort unag.tavg = .false. 

Time-averaged vorticity magnitude 
vort_x_tavg = .false. 

Time-averaged x-component vorticity 
vort_y_tavg = .false. 

Time-averaged y-component vorticity 
vort_z_tavg = .false. 

Time-averaged z-component vorticity 
primitive_trms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of x-component of velocity 

v_trms = .false. 

RMS-average of y-component of velocity 

w_trms = .false. 

RMS-average of z-component of velocity 
p_trms = .false. 

RMS-average of pressure 
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lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda3 = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda4 = .false. 

Adjoint Lagrange multiplier for equation 4 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda5 = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda6 = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda7 = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor.id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 
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turb_diss = .false. 

Turbulence dissipation rate 
mu_t_wf = .false. 

Turbulent eddy viscosity at the wall from a wall function model. 
mu_t = .false. 

Turbulent eddy viscosity 

turbl = .false. 

Turbulence variable 1 (model dependent) 
turb2 = .false. 

Turbulence variable 2 (model dependent) 

turb3 = .false. 

Turbulence variable 3 (model dependent) 

turb4 = .false. 

Turbulence variable 4 (model dependent) 

turb5 = .false. 

Turbulence variable 5 (model dependent) 

turb6 = .false. 

Turbulence variable 6 (model dependent) 

turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turres3 = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turres5 = .false. 

Residual of 5th turbulence equation 
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turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
slen = .false. 

Length to the nearest solid wall boundary 
iflagslen = .false. 

Turbulence model distance function closest boundary entity, (a negative 
sign indicates the node has been prescribed as laminar) 

hrles_blend = .false. 

HRLES blending function 

vort_x_rms = .false. 

RMS-average of x- component of vortic-ity 

vort_y_rras = .false. 

RMS-average of ^/-component of vorticity 

vort_z_rms = .false. 

RMS-average of z-component of vorticity 

vort_mag_rms = .false. 

RMS-average of vorticity magnitude 

yplus = .false. 

Dimensionless wall distance, y + 

cmu_star = .false. 

k — e model turbulent length scale parameter 

mu_t_ratio = .false. 

Ratio of turbulent eddy viscosity to laminar (bulk) viscosity 
iib = .false. 

— trace(R,;j * B ^)/ 2 
iiib = .false. 
trace (Ry * B ^ * Bij )/ 3 
uplus = .false. 

Dimensionless velocity, u + 
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kplus = .false. 


_k_ 

«? 

wplus = .false. 

UW_ 

ul 

yplusretau = .false. 


re T 


tllplus = 

.false. 

Til 


tl2plus = 

.false. 

Tl2 


tl3plus = 

.false. 

T 13 


t22plus = 

.false. 

r + 

'22 


t23plus = 

.false. 

r + 

'23 


t33plus = 

.false. 

r + 

'33 


bird_breakdown = .false. 

Bird continuum breakdown parameter 
vgradrho = .false. 

[u, v, w] ■ Vp 
f_rl = .false. 

Curvature correction model function 
xi_k = .false. 

Cross-diffusion term for Wilcox k-uj 1998 
reconstruction_liraiter_phil = .false. 

(j) for the node-based reconstruction limiters 
reconstruction_liraiter_phi2 = .false. 

0 for the node-based reconstruction limiters 


(equation 1) 
(equation 2) 
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reconstruction_liraiter_phi3 = .false. 

0 for the node-based reconstruction limiters (equation 3) 


reconstruction_liraiter_phi4 = .false. 

0 for the node-based reconstruction limiters (equation 4) 
reconstruction_limiter_phi5 = .false. 

0 for the node-based reconstruction limiters (equation 5) 
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B.4.26 &:sampling parameters 


This namelist specifies the types and frequency of sampling data to be ex- 
ported for visualization. The output variables themselves are specified in the 
&sampling_output_variables namelist. The last dimension of each array 
references the geometry index, which is one to number_of ^geometries. 

& s amp 1 i ng_p ar ame t e r s 


number _of _geometries 

= 

0 

sampling_f requency ( : ) 

= 

0 

label ( : ) 

= 

1 1 

type_of _geometry ( : ) 

= 

1 none ' 

crinkle 

= 

.false . 

nodal 

= 

.false . 

plot ( : ) 

= 

' tecplot 

patch_list_count ( : ) 

= 

0 

patch_list ( : ) 

= 

1 1 

type_of _data( : ) 

= 

' volume ' 

move_with_body ( : ) 

= 

i i 

boundary_list 

= 

i i 

def ault_boundary 

= 

. true . 

plane_center (1:3, : ) 

= 

0.0 

plane_normal (1:3, : ) 

= 

0.0 

box_lower_corner (1 :3, : ) 

= 

0.0 

box_upper_corner (1 :3, : ) 

= 

0.0 

sphere_center (1:3, : ) 

= 

0.0 

sphere_radius ( : ) 

= 

0.0 

circle_center (1 :3, : ) 

= 

0.0 

circle_normal (1 : 3 , : ) 

= 

0.0 

circle_radius ( : ) 

= 

0.0 

cylinder_f acel (1 :3, : ) 

= 

0.0 

cylinder_f ace2(l :3, : ) 

= 

0.0 

cylinder_radius ( : ) 

= 

0.0 

cone_f acel (1 : 3 , : ) 

= 

0.0 

cone_f ace2(l : 3 , :) 

= 

0.0 

cone_radiusl ( : ) 

= 

0.0 

cone_radius2 ( : ) 

= 

0.0 

cornerl(l :3, : ) 

= 

0.0 

corner2(l :3, : ) 

= 

0.0 

corner3(l :3, : ) 

= 

0.0 

corner4(l :3, : ) 

= 

0.0 

number_of _points ( : ) 

= 

0 

points (1 : 3 , : , : ) 

= 

0.0 

number _of _lines 

= 

0 

pl_line(l :3, : ) 

= 

0.0 

p2_line(l :3, : ) 

= 

0.0 
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schlieren_aspect = ' ' 

window_height ( : ) = 0.0 

window_width ( : ) =0.0 

window_center (1 :3, : ) = 0.0 

number_of _rows( : ) = 0 

number_of _columns ( : ) = 0 

model_center (1 : 3 , : ) = 0.0 

plot_lines ( : ) = .false. 

make_shadow = .false. 

blanking_list_count ( : ) = 0 

blanking_list ( : ) = 11 

isosurf _variable( : ) = 1 p 1 

isosurf _value (: ) = 0.0 

isosurf _box( : ) = .false. 

x_range_lower ( : ) = -1.0 

x_range_upper ( : ) =1.0 

y_range_lower ( : ) = -1.0 

y_range_upper ( : ) =1.0 

z_range_lower ( : ) = -1.0 

z_range_upper ( : ) =1.0 

isosurf _dist_threshold( : ) = 0.0 

variable_list ( : ) = 11 

snap_output_xyz = .true. 

dist_tolerance = 1.0e-3 

fwh_f ormatted = .false. 

append_history ( : ) = .false. 

asynchronous_fwh = .false, 

ref erence_length = 0.0 

/ 

number.of .geometries = 0 


This is the total number of sampling geometries. 


sampling.f requency ( : ) = 0 

This specifies the iteration interval at which sampling is performed. The 
special value of -1 means to only perform sampling at the end of a 
successful run. 

label ( : ) = » > 


This customizes the filename of sampling output. When it is blank, the 
file will be [project_rootname] _tec_sampling_geomN. (dat , pit) where 
N is the sampling geometry number, .dat is ASCII format, and .pit is 
binary format. 


type.of .geometry (: ) = ’none’ 

This is the type of sampling geometry, 
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' streamsurf ace ’ is a stream surface, requires number.of .points and 
points. 

' boundary.points ’ for boundary point sampling, requires number.of .points 
and points, modified by snap_output_xyz and dist.tolerance. 

' volume.points ’ for point sampling in the domain, requires number.of .points 
and points. 

' schlieren’ is a schlieren image via an integral of the refractive index 
held, requires number.of .rows, number.of .columns, windowJieight, window.width, 
window.center, and schlieren_aspect. It is controlled by make.shadow 
and plot_lines. 

' isosurface ’ is an isosurface that recjuires isosurf .variable and isosurf .value. 
It is controlled by *_range_lower and *_range_upper. 

‘ box’ samples a the surface of a box. It requires box.lower.corner and 
box.upper .corner. 

‘ sphere J samples a spherical surface. It requires sphere.center and 
sphere_radius. 

'cylinder’ samples a cylindrical surface. It requires cylinder.f acel, 
cylinder.f ace2, and cylinder_radius. 

'cone’ samples a conic surface. It requires cone_facel, cone_face2, 
cone_radiusl, and cone_radius2. 

'plane’ samples a plane. It requires plane.center and plane .normal. 

'quad’ samples a quadrilateral. It requires cornerl, corner2, corner3, 
corner4, and window_normal. 

'circle’ samples a circle. It requires circle.center, circle morraal, 
and circlevradius. 

' line’ is line sampling, which requires number.of .lines, pl.line, and 
p2_line. 

crinkle = .false. 

This snaps the sampling surface to nearest grid faces instead of using 
linear interpolation. 

nodal = .false. 

This uses the nearest nodal values instead of interpolating. 

plot(:) = ’tecplot’ 

This is the format of sampling output, 

'tecplot’ Tecplot™ format. 
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‘fwh’ format for Ffowcs Williams-Hawkings analysis. 

‘ serial_history 5 custom low-overhead point sampling format where 
all locations listed once at the top and then just the requested values 
per sampling_frequency. 

patch.list.count ( : ) = 0 

This is the number of patches in patch.list. 

patch.list ( : ) = ’ ’ 

A string list of patch face IDs to limit boundary survey to a subset of 
the boundary faces. Commas and dashes can be used to specify ranges, 
i.e., ’ 1 , 2 , 5 - 7 ’. 

type.of _data( : ) = ’ volume’ 

The source of data for extracting the requested sampling variables for 
each type_of .geometry. 

‘ volume J extract data from the computational volume. 

‘ boundary ’ extract data from a boundary. 

move_with_body ( : ) = ’ ’ 

Move the sampling geometry with the body if body is in motion. Use 
the fixed inertial reference frame when blank. 

boundary.list = ’ ’ 

List of patches to include when sampling boundaries; Commas and 
dashes can be used to specify ranges, i.e., ’ 1 , 2 , 5-7 ’ . 

default .boundary = .true. 

Use FUN3D default solid-wall-only boundary patches when sampling 
boundary points, i.e., ignore symmetry, slip, and flow-through bound- 
aries. 

plane.center (1 : 3, : ) = 0.0 

This is a point on a requested sampling ’ plane J ; it fixes the location, 
plane mormal (1 : 3, : ) = 0.0 

This is a normal vector of sampling J plane 5 ; it fixes the orientation. 

box.lower.corner (1 : 3, : ) = 0.0 

This is the coordinate of the lower corner of a J box ’ . 

box.upper.corner (1 : 3, : ) = 0.0 

This is the coordinate of the upper corner of a ’ box ’ . 
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sphere.center (1 : 3 , : ) = 0.0 

This is the coordinate of ’ sphere ’ center; it fixes the location. 
sphere_radius ( : ) = 0.0 

This is the radius for ’ sphere ’ ; it fixes the size, 
circle.center (1 : 3 , : ) = 0.0 

This is the coordinate of center of a ’ circle ’ ; it fixes the location. 
circle_normal(l :3, : ) = 0.0 

This is the normal vector for a ’ circle ’ ; it fixes the orientation. 
circle_radius ( : ) = 0.0 

This is the radius for a ’ circle’ ; it fixes the size. 
cylinder_f acel (1 : 3, : ) = 0.0 

This is the coordinate for the center of the first face of a ’ cylinder’ . 
cylinder^ ace2(l : 3, : ) = 0.0 

This is the coordinate for center of the second face of a ’ cylinder’ . 

cylinder_radius ( : ) = 0.0 
This is the radius of a ’ cylinder’ . 

cone_f acel (1 : 3 , : ) = 0.0 

This is the coordinate for center of the first face of a ’ cylinder’ . 
cone_f ace2 (1 : 3 , : ) = 0.0 

This is the coordinate for center of the second face of a ’ cylinder’ . 
cone_radiusl ( : ) = 0.0 

This is the radius of the first face of a ’ cone ’ . 
cone_radius2 ( : ) = 0.0 

This is the radius of the second face of a ’ cone ’ . 
cornerl (1 : 3, : ) = 0.0 

This is the coordinate of the first corner of a ’ quad ’ ; the corners proceed 
clockwise. 

corner2 (1 : 3, : ) = 0.0 

The coordinate of the second corner of a ’ quad ’ . 
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corner3(l : 3, : ) = 0.0 

The coordinate of the third corner of a ’ quad ’ . 
corner4(l : 3, : ) = 0.0 

The coordinate of the fourth corner of a ’ quad ’ . 
number_of ^points ( : ) = 0 

This is the number of points to be sampled by ’ boundary_point ’ or 
’ volume.point ’ . 

points (1 : 3, : , : ) = 0.0 

These are the coordinates of boundary.point and volume_point sam- 
pling. The first index is the Cartesian direction, the second index is the 
geometry, and the last index is the point in this geometry. 

number_of _lines = 0 

This is the number of lines in ’ line’ sampling. 
pl_line(l:3, :) =0.0 

This is the first end point of a line in line sampling. 
p2_line(l :3, : ) = 0.0 

This is the second end point of a line in line sampling, 
schlieren.aspect = 3 3 

This is the Cartesian direction for ’schlieren’ view, 

‘ y ’ Schlicren viewing along y axis. 

‘ z 3 Schlicren viewing along z axis. 

‘ yl ’ Schlicren viewing along y axis. 

'zl’ Schlieren viewing along z axis. 

‘ 3 Schlieren viewing along window_normal. 

window_height ( : ) = 0.0 

This is the window height for 3 schlieren’ . 

window_width( : ) = 0.0 

This is the window width for ’ schlieren’ . 

window.center (1 : 3 , : ) = 0.0 

This is the window center for ’ schlieren’ . 
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number_of _rows ( : ) = 0 

This is the vertical number of pixels in the ’ schlieren’ window. 
number_of .columns (: ) = 0 

This is the horizontal number of pixels in the ’ schlieren’ window. 

model.center (1 : 3, : ) = 0.0 

This is the model center for ’ schlieren’ . 

plot.lines ( : ) = .false. 

This plots lines for ’ schlieren’ . 
make.shadow = .false. 

The boundary will cast a shadow in schlieren output, 
blanking.list.count ( : ) = 0 

This is the number of boundaries to search for ’ schlieren ’ boundary 
shadow. 

blanking.list ( : ) = ’’ 

This is a list of boundaries to search for ’ schlieren’ shadow. Commas 
and dashes can be used to specify ranges, i.e. , ’1,2, 5-7’ . 

isosurf .variable ( : ) = ’p’ 

This is the variable used to define the geometry of an ’ isosurface ’ and 
isocrinkle. 

‘ p ’ Pressure. 

‘ rho ’ Density. 

‘u’ X-cornp orient of velocity. 

‘ v ’ Y -component of velocity. 

‘ w ’ Z-component of velocity. 

'vort_x’ X-component of vorticity. 

'vort.y’ y-component of vorticity. 

'vort_z’ Z-component of vorticity. 

'vortunag’ Total magnitude of vorticity vector. 

‘ vort unag.avg’ Average total magnitude of vorticity vector. 

‘ vort unag_rms ’ RMS total magnitude of vorticity vector. 

‘ q.criterion’ Q-criterion. 

‘ mach ’ Mach number. 
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'temperature’ Temperature. 

'p_tavg’ Time average pressure. 

'rho.tavg’ Time average density. 

'u_tavg’ Time average ^-component of velocity. 

'v_tavg’ Time average ^/-component of velocity. 

'wrtavg’ Time average ^-component of velocity. 

' p_trms ’ RMS of pressure. 

' rho.trms ’ RMS of density. 

' urtrms ’ RMS of the ^-component of velocity. 

' v_trms ’ RMS of the ^/-component of velocity. 

' w_trms ’ RMS of the ^-component of velocity. 

'critical.d’ critical d 
' sla’ other option 
'sib’ other option 
' si ’ other option 
' s2 ’ other option 

' lambdal ’ Adjoint variable for the 1st governing equation. 

' lambda2 ’ Adjoint variable for the 2nd governing equation. 

' lambda3’ Adjoint variable for the 3rd governing equation. 

' lambda4’ Adjoint variable for the 4th governing equation. 

' lambda5 ’ Adjoint variable for the 5th governing equation. 

' lambda6 ’ Adjoint variable for the 6th governing equation. 

' lambda7’ Adjoint variable for the 7th governing equation. 

' processor_id’ The assigned processor ID. 

' bird_breakdown’ Bird breakdown factor. 
isosurf _value( : ) = 0.0 

This is the value of isosurf _variable( : ) to create the ’isosurface’ 
and isocrinkle geometry. 

isosurf _box( : ) = .false. 

This clips the sampling geometry to be inside a box sized by *_range_* 
within isosurf _dist_threshold. 

x_range_lower ( : ) = -1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
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x_range_upper ( : ) = 1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
y_range_lower ( : ) = -1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
y_range_upper ( : ) = 1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
z_range_lower ( : ) = -1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
z_range_upper ( : ) = 1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
isosurf _dist_threshold( : ) = 0.0 

This trims portions of an isosurface or isocrinkle that have a dis- 
tance to the surface less then this threshold. It requires isosurf _box( : 

) = .true. 

variable_list ( : ) = ’’ 

These variables augment &sampling_output_variables for this sam- 
pling object. 

snap_output_xyz = .true. 

This snaps the requested points to the nearest surface. 

dist.tolerance = 1.0e-3 

This is the tolerance used when snap_output_xyz is engaged. 
fwh_f ormatted = .false. 

Write Ffowcs Williams-Hawkings in Fortran unformatted format. The 
default is Fortran stream (C-binary). 

appendJiistory ( : ) = .false. 

This option removes the step number from the filename and opens it 
with append. 

asynchronous_fwh = .false. 

This uses asynchronous I/O for permeable FWH output, 
ref erencedLength = 0.0 

This is the reference length for Re r used in &sampling_output_variables. 
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B.4.27 &slice data 


This namelist specifies boundary slices for visualization and to obtain loads. 
Output frequency is controlled by sliced: req in the &global namelist, where 
zero for no output, -1 for output at the end of run, and a positive integer for 
periodic output. 

This is a limited ability to take slices through boundary surfaces. For 
example, spanwise cuts along a wing may be extracted, and then the resulting 
pressure and skin friction data may be plotted at each station. Slices can 
only be extracted in Cartesian planes (e.g., constant y ). For moving-body 
cases, the slices may be taken at constant coordinate positions in the body-fixed 
coordinate system, in which case the slices will not generally be in Cartesian 
planes in inertial space. 

The sliced data is written to an ASCII formatted Tecplot™ file with the 
naming convention: 

[pro j ect_rootname] _slice . dat 

The variables output to this file are: x, y, z, cp, cfx, cfy, and cfz at each 
output time step. The slicing output variables are not customizable by the 
user. 

Slicing occurs in the inertial frame, unless an alternate reference frame is 
specified. For stationary geometries, the inertial frame is the only option. For 
moving body cases, either the frame of one of the moving bodies or an observer 
frame may specified. 

When slicing boundary surfaces, a file called slice. info is output that 
echos much of the input data. When the slicing is successful, the file will also 
contain information about the number of points in the slice. 

Below, namelist variables are defined. See section B.4.27 for some impor- 
tant considerations when using this capability. 

&slice_data 


nslices 

= 

1 

replicate_all_bodies 

= 

.false . 

slice_x( : ) 

= 

.false . 

slice_y ( : ) 

= 

. true . 

slice_z( : ) 

= 

.false . 

slice_location( : ) 

= 

0.0 

si ice_ increment 

= 

0.0 

xx_box_max( : ) 

= 

huge (1 . 0) 

yy_box_max( : ) 

= 

huge (1 . 0) 

zz_box_max( : ) 

= 

huge (1 . 0) 

xx_box_min( : ) 

= 

-huge (1 . 0) 

yy_box_min( : ) 

= 

-huge (1 . 0) 

zz_box_min( : ) 

= 

-huge (1 . 0) 
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slice_xmc ( : ) 


= 

huge (1 . 0) 


slice_ymc ( : ) 


= 

huge (1 . 0) 


slice_zmc ( : ) 


= 

huge (1 . 0) 


n_bndrys_to_slice ( : ) 


= 

0 


bndrys_to_slice ( : , : ) 


- 

0 


slice_f rame ( : ) 


= 

1 1 


slice_group( : ) 


= 

1 


chord_dir ( : ) 


= 

1 


te_def ( : ) 


= 

1 


le_def ( : ) 


= 

30 


corner_angle ( : ) 


= 

120.0 


use_local_ chord 


= 

. true . 


tecplot_slice_output 


= 

. true . 


output _sectional_f or ces 

= 

. true . 


slice_initial_coords 


= 

.false . 


custom_transf orm(l , 1 , 

1:4) 

= 

1.0, 0.0, 

0.0, 0.0 

cust om_tr ansf orm ( 1 , 2 , 

1:4) 

= 

0.0, 1.0, 

0.0, 0.0 

custom_transf orm(l ,3, 

1:4) 

= 

0.0, 0.0, 

1.0, 0.0 

custom_transf orm(l ,4, 

1:4) 

= 

0.0, 0.0, 

0.0, 1.0 

output_in_slice_coords( : ) 

= 

.false . 



nslices = 1 

This is the number of slices to create. If negative, then data for only 
one slice station need be input, along with slice_increment, and all the 
data specified for the first station will be applied to subsequent stations, 
with the exception of the slice location, which will be set using the slice 
increment between stations. 

replicate_all_bodies = .false. 

This will set similar slice stations on multiple bodies with minimal input 
beyond that required for slicing the first body. This is particularly useful 
for rotorcraft applications where multiple blades are to be sliced. This 
variable duplicates the input slice info for all moving bodies, with the 
exception of the slice_frame and the bndrys_to_slice. 

slice_x(:) = .false. 

This extracts the slice at x — slice_location in the specified reference 
frame. 

slice_y(:) = .true. 

This extracts the slice at y — slice.location in the specified reference 
frame. 
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slice_z(:) = .false. 

This extracts the slice at z — slicedLocation in the specihed reference 
frame. 

slice_location( : ) = 0.0 

This is the coordinate value at which slice is taken. 
slice_increment = 0.0 

When nslices is negative, this is the increment in slice coordinate be- 
tween consecutive slice stations. 

xx_box_max ( : ) = huge (1.0) 

This is the maximum ^-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

yy_box_max ( : ) = huge (1.0) 

This is the maximum //-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

zz_box_max ( : ) = huge (1.0) 

This is the maximum z-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

xx_box_min( : ) = -huge(l.O) 

This is the minimum ^-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

yy_box_min( : ) = -huge (1.0) 

This is the minimum //-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

zz_boxunin( : ) = -huge(l.O) 

This is the minimum z-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

slice_xmc(:) = huge (1.0) 

This is the ^-coordinate of the moment center, in the specihed reference 
frame, for aerodynamic moments acting on the slice. The default value 
’’huge” will result in the moment center being taken as the computed 
quarter chord of the slice. 

slice_ymc ( : ) = huge (1.0) 

This is the //-coordinate of the moment center, in the specihed reference 
frame, for aerodynamic moments acting on the slice. The default value 
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’’huge” will result in the moment center being taken as the computed 
quarter chord of the slice. 

slice_zmc(:) = huge(l.O) 

This is the ^-coordinate of the moment center, in the specified reference 
frame, for aerodynamic moments acting on the slice. The default value 
’’huge” will result in the moment center being taken as the computed 
quarter chord of the slice. 

n_bndrys_to_slice ( : ) = 0 

This is the number of candidate boundaries to search while computing 
slice-plane intersections. The index is the slice. By default, all solid 
boundaries will be searched. Specifying which boundaries are candidates 
for slicing may speed up the slicing process and can be used to filter out 
unwanted intersections or to slice non-solid boundaries. 

bndrys_to_slice( : , : ) = 0 

This is the list of n_bndrys_to_slice boundaries, when the variable 
nfbndrys.to.slice is greater than zero. The first index is the slice 
and the second index is the boundary. 

slice_frame( : ) = ’’ 

This is the name of the slice reference frame. Blank indicates the iner- 
tial frame. For moving geometries, output may be requested in either 
the reference frame of a particular body, or an “observer” frame. To 
specify the frame of a particular body, use the body .name entered in the 
febody .definitions namelist. To specify the observer frame defined in 
the &observer_motion namelist, use ’observer’. 

slice_group( : ) = 1 

This assigns this slice to a particular group number. Within a group, 
slice locations must be given in ascending order. 

chord_dir(:) = 1 

This is the direction of local chord relative to the direction from leading 
edge to trailing edge, in the slice plane. The value 1 indicates local chord 
in direction from leading edge to trailing edge. The value —1 indicates 
local chord in direction from trailing edge to leading edge. Determination 
of the leading and trailing edges is described below. 

te_def ( : ) =1 

This is the number of points or line segments to consider when defining 
the trailing edge of the slice (see Fig. B2). A value of 1 defines the 


206 


trailing edge as the aft-most point. This is best for sharp trailing edges. 
A positive number greater than 1 initiates a search over the aft-most 
te_def segments for corners, after which the trailing edge is taken as 
the average coordinate over all the detected corners. Two corners are 
assumed to be the desired number, and warnings are output if only 
one or more than two are found. The value of te_def must be chosen 
judiciously. It should be large enough to allow both corners to be found 
but not so large as to cause excessive searching or for any non-trailing 
edge corners to be found. A positive value of te_def is best for and 
recommended only for squared-off trailing edges. A negative number 
indicates a parabolic fit of the aft-most abs(te_def) points, which is 
best for rounded or blunted trailing edges. 

le_def ( : ) = 30 

This is the number of points to consider when defining the leading edge 
of the slice (see Fig. B3). A value of 1 defines the leading edge as the 
forward-most point. Use this if nothing else works or for special cases. A 
positive number indicates a search over the forward-most le_def points 
for the one that has the maximum distance from the previously deter- 
mined trailing edge. A positive number for le_def is generally the best 
choice provided that the trailing edge can be accurately located. A nega- 
tive number indicates a parabolic fit over the forward- most abs(le_def) 
points. 

corner.angle ( : ) = 120.0 

This is used in conjunction with a te_def greater than 1. Angles between 
adjacent sliced segments that are less than corner_angle degrees will be 
considered a corner between the two segments. For squared-off trailing 
edges, two and only two corners should be detected; warnings are output 
if only one or more than two are found. 

use_local_chord = .true. 

Use the computed local (sectional) chord based on the computed lead- 
ing edge and trailing edge locations to normalize the sectional force 
and moment data. When .false., the value of x_moment_length in 
&f orceunoment_integ_properties will be used instead of the locally 
computed chord. 

tecplot_slice_output = .true. 

This outputs the sliced data to a formatted Tecplot™ hie that is named 
[project_rootnamej_slice.dat. This hie can become very large for 
unsteady hows with frequently written data at many slice locations. 
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output_sectional_f orces = .true. 

This outputs detailed force and moment data for each slice to a formatted 
hie, [project_rootname] .sectional_f orces. This hie contains force 
and moment data, like that in the [project_rootname] .forces hie, for 
each and every slice. In addition, it contains geometrical data for each 
slice (leading and trailing edge coordinates, moment center, etc.) This 
file can become very large for unsteady hows with frequently written data 
at many slice locations. The data in the hie, especially the geometry 
data, can be useful to assess whether the slicing is working as expected. 

slice_initial_coords = .false. 

This allows faster slicing for some cases by only computing slice inter- 
polation coefficients once. 

custom.transf orm(l , 1 , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow slicing in a custom 
coordinate system. 

output_in_slice_coords ( : ) = .false. 

This outputs sliced data in the user-specihed coordinate system. The 
default outputs the data in the slice_f rame, which is only available if 
custom.transf orm is set. 

Important Considerations for Determination of Leading And Trail- 
ing Edges Determining the locations of airfoil leading and trailing edges 
is especially important for rotorcraft applications where airloads are usually 
examined (and provided to a CSD code, if applicable), in an airfoil section- 
aligned coordinate system. The leading and trailing edge points determine the 
orientation of this section aligned coordinate system. In the section-aligned 
system, the local x coordinate is aligned with the local chord, positive in the 
direction from the leading edge to the trailing edge. The local span direction is 
defined by the moment centers at the slice_location points, positive in the 
direction of increasing slice_location. The local normal direction is defined 
as the cross product of the local chord vector and local span vector. When 
slicing boundary data, the computed forces are computed in both the selected 
frame of reference (see slice_frame) and in an airfoil section aligned system. 
If the data in the section-aligned system is irrelevant to you, then you do not 
need to worry about choosing the detection parameters carefully; the default 
values should be reasonable. However, if resolution of forces and moments 
into a section- aligned system is important to you, then there are a number of 
things that should be considered: 

1. Make sure the chord direction chord_dir is correct; the default is that 
going from the leading edge to the trailing edge is the same as traveling in 
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the positive “chordwise” coordinate direction. For most applications this 
is the usual situation; however, the convention for rotorcraft applications 
is the opposite, requiring chord.dir = -1. 

2. Since the best option for determining the leading edge uses the trailing 
edge location (le_def > 1), care should be taken to get the trailing edge 
correct. For sharp trailing edges, this is very simple since the default of 
te_def = 1 (i.e. , use the aft-most point) is the best option. However, 
smoothly blunted or squared-off trailing edges are more difficult. When 
the boundary surface of an unstructured mesh is sliced, the resulting 
section will be comprised of line segments determined by the intersec- 
tion of the specified plane and the edges of the surface triangles. These 
segments and the points that make up the segments will not usually be 
the same as the surface points; typically there are more segments and 
points arising from intersected triangles, as illustrated in Fig. Bl. This 
greater point count should influence the selection of te_def and le_def 
values. You will need enough segments (te_def and le_def) to ensure 
that both corners are detected, but not so many that other, non trailing- 
edge corners (if present) are detected. Another parameter that may be 
of use to aid in the detection of corners is the corner.angle; corners 
with angles larger than corner.angle between adjacent segments will 
require a larger value of corner_angle for detection. 

The resulting section corresponding to the slice depicted in Fig. Bl is 
shown in Fig. B2, where the view is zoomed in to the trailing edge 
region. The aft-most 8 segments (of the approximately 30 segments in 
this view) are shown in red. The computed trailing edge locations using 
two different te_def values are shown. The minimum te_def value at 
this particular station to pick up both corners would be 8, but a value of 
20 was used in case another slice required more segments. If the blade 
was pitched downward rather than upward, then the point chosen by 
te_def = 1 would be the lower corner, rather than the upper corner as 
shown. Thus, when pitching up and down, te_def = 1 with squared-off 
trailing edges can lead to jumps in the trailing edge position as the section 
transitions from pitch up to pitch down. Depending on the thickness of 
the trailing edge, this can lead to jumps in the geometric pitch angle of a 
few tenths of a degree. To avoid this, the option slice_initial_coords 
= .true, will reuse the leading and trailing edges determined from the 
initial grid definition, rather than the current, displaced grid location. 

3. Smoothly-blunted (rounded) trailing edges should be done with either 
te_def = 1 (aft-most point) or via a parabolic fit of the aft-most 
abs(te_def) points; the latter option is probably better in general but 
will require some experimentation for the particular case at hand to 
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choose the optimal number of points over which to fit the parabola. 

4. The leading edge is typically easier to determine, if a good trailing edge 
position has already been found. The default value of le_def = 30 
(search the 30 forward-most points for the one with the greatest dis- 
tance from the trailing edge location) should do a decent job for most 
cases. 

Figure B3 shows a sliced section, zoomed in to the leading edge region. 
The forward-most 20 segments (of the approximately 30 segments in this 
view) are shown in red. The computed leading edge locations using two 
different le_def values are shown. In this case, both results are fairly 
close but le_def = 30 has picked out the true leading edge (as judged 
from the leading edge geometry at zero pitch angle). 

5. The leading edge and trailing edge detection schemes can be somewhat 
sensitive to the input choices. For cases that rely on accurate resolution 
of forces and moments into section- aligned coordinates (e.g., rotorcraft), 
it is wise to spend some time up front to make sure that things are 



Figure Bl: View looking upstream from the trailing edge of a rotor blade 
mesh; the light-colored region is the squared-off trailing edge; the red line 
shows the location where an x=constant slice will be taken; black circles 
indicate surface grid points on the trailing edge. 
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coming out as expected. To do this, inspect the [project_rootname] 
,sectional_f orces hie for a particular slice station; at each station the 
computed leading and trailing edge coordinates will be output. Plot 
the corresponding station from the [project_rootnamej_slice.dat, as 
done above, and make sure the computed coordinates are the correct 
ones. If many stations are sliced, it is impractical to inspect all of 
them in this manner, but it is good practice to spot check at least a 
few stations. For moving-geometry cases, try first running the case with 
--body_motion_only. That will allow output of the [project_rootname] 
,sectional_f orces and [project_rootnamej_slice.dat hies without 
the expense of a how solve or mesh deformation; for spot checking you 
may want to have the slicing done infrequently, perhaps using fewer sta- 
tions than ultimately desired, as these output hies can be huge. 

6. While the [project_rootname] ,sectional_f orces can be useful for 
spot checking, the data in the hie is not in a format that is amenable to 
plotting. The Fun 3D distribution utils/Rotorcraft directory con- 
tains a utility code that will read in both the hies slice. info and 
[project_rootname] ,sectional_f orces to output Tecplot™ hies, for 
each slice group, containing force and moment data in the section-aligned 



Figure B2: Sliced section corresponding to Fig. Bl; zoomed in to the 
trailing edge region. 
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coordinate system, as well as geometry data (leading edge, trailing edge, 
quarter-chord coordinates, and pitch angle). 

7. After making sure that the leading edge and trailing edge positions are 
being computed correctly, you may want to turn off one or both of 
the [project_rootname] ,sectional_f orces and [project_rootname] 
_slice.dat hies unless needed. For instance, in rotorcraft applications 
with coupling to external CSD codes, although the blade boundary sur- 
faces must be sliced to generate the aerodynamic loads data for the CSD 
code, this information is actually passed to the CSD code by another hie; 
the [project_rootname] .sectional_f orces and [project_rootname] 
_slice.dat hies are not used. 

8. Although the slicing process will work for multi-element airfoils, at this 
time the computation of the leading edge and trailing edge is only done 
for the entire section, not each element individually. 



0.4 0.45 0.5 


X 

Figure B3: A sliced section, zoomed in to the leading edge region. 
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B.4.28 &:overset data 


This namelist specifies information for overset grid simulations. 


&overset_data 


overset_f lag 

= 

.false . 

dci_on_the_f ly 

= 

.false . 

dci_period 

= 

huge(l) 

reset_dci_period 

= 

.false . 

dci_freq 

= 

1 

dci_dir 

= 

1 1 

reuse_existing_dci 

= 

.false . 

skip_dci_output 

= 

.false . 

dci_io 

= 

.false . 

dci_io_nproc 

= 

1 

use_imesh_ constraint 

= 

. true . 

suggar_nproc 

= 

1 


/ 

overset_flag = .false. 

When .true., overset mesh capability is enabled. 

dci_on_the_f ly = .false. 

This controls whether overset connectivity is computed as the grid moves, 
or whether overset connectivity has been pre-computed for each grid 
position and is available to read in. Ignored if overset.flag = .false, 
and &rotor_data’s overset_rotor = .false.. 

dci.period = huge(l) 

This controls the period (in term of timesteps) at which the dci counter 
is reset. At time step dci.period, the flow solver will read dci data 
from the dci file for time step 1. Ignored if overset_f lag = .false, and 
&rotor_data’s oversetvrotor = .false.. 
reset_dci_period = .false. 

When .true., allows dci.period to be reset to a different value for 
restarting with a different time step. 

dci_freq = 1 

This controls how frequently the dci data is updated, either by compu- 
tation within the flow solver, or by reading a new dci file. Dci data is 
updated every dci_freq time steps. 

dci.dir = ’ . 1 

This is the directory where dci files are located. Note: A trailing for- 
ward slash (/) is automatically added and should not be included in the 
directory name. 
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reuse_existing_dci = .false. 

When .true., allows the computation of dci data to be skipped if a dci 
file for the current time step already exists. This option is typically used 
in conjunction with dci_period, so that dci hies are computed on the fly 
for the first dci_period time steps, and then hies are reused for all subse- 
quent periods of grid motion, without having to change dci_on_the_f ly 
in between. Ignored if dci_on_the_f ly = .false.. 

skip_dci_output = .false. 

When .true., the solver will not save the dci data to a hie. Ignored if 
dci_on_the_f ly = .false.. 

dci_io = .false. 

When .true., dci hies are read from disk with a dedicated rank (proces- 
sor) to help mask communication with computation. 

dci_io_nproc = 1 

When dci_io = .true., this specihes the number of ranks to use for 
loading of dci hies. 

use_imesh_constraint = .true. 

When .true., the irnesh value is taken into account when partitioning, 
suggarmproc = 1 

This specihes the number of ranks to use for running libSUGGAR++ 
Intended for future expansion; currently must be 1. 
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B.4.29 &rotor data 


This namelist controls high-level rotor simulation settings. Eventually, this 
namelist may subsume rot or. input. 

&rotor_data 

comprehensive_rotor_coupling = 'none' 
overset_rotor = .false. 

/ 


comprehensive_rotor_coupling = ’none’ 

This controls whether the code is to be coupled to a rotorcraft compre- 
hensive code, and if so, which one. 

‘ none ’ not coupled. 

< camrad J coupled to CAMRAD-II. 

‘rcas’ loosely coupled to RCAS. 

‘rcas-tight’ tightly coupled to RCAS. 

‘fsi’ tightly coupled to DYMORE. 

overset_rotor = .false. 

This controls whether overset meshes are used for moving rotor simula- 
tions. When .true., the rotor motion is governed by the rotor. input 
file. 
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B.4.30 &adapt metric construction 

This namelist controls how the metric is formed for metric-based mesh adap- 
tation. More details on grid adaptation can be obtained in section 7. 

&adapt_metric_const ruction 


adapt _he s s i an_key 

= 

1 mach 1 

adapt _hessian_method 

= 

1 lsq 1 

adapt _max_anisotropy 

= 

1 . 0e6 

adapt _max_edge_growth 

= 

2.0 

adapt _max_edge_ length 

= 

-1.0 

adapt _min_edge_ length 

= 

-1.0 

adapt _output_tolerance 

= 

-0.5 

adapt _complexity 

= 

-1.0 

adapt _gradat ion 

= 

-1.0 

adapt _err or _estimat ion 

= 

1 embed 1 

adapt _exponent 

= 

0.2 

adapt _feature_scalar_key 

= 

1 density 

adapt _f eature_scalar_f orm 

= 

1 delta 1 

adapt _feature_length_exp 

= 

0.5 

adapt _ inter sect _metric_in_time 

= 

.false . 

adapt_metric_f rom_f ile 

= 

1 1 

adapt _export_metric 

= 

.false . 

adapt _twod 

= 

.false . 

adapt_verbose 

= 

.false . 

adapt _export_f eature_scalar_key 

= 

1 none 1 

adapt _visualize_metric 

= 

1 none 1 

adapt _current_h_method 

= 

1 edge 1 

adapt _curr ent _h_gr adat ion 

= 

1.5 


adapt Ties siamkey = ’mach’ 

This variable is used to define anisotropic Hessian, 

' raach ’ is Mach number. 

'pressure’ is pressure. 

' entropy ’ is entropy. 

'temp’ is temperature. 

'density’ is density. 

' vorticity-magnitude ’ is the magnitude of the vorticity vector. 
adapt_hessian_method = ’lsq’ 

This is the mathematical method used to recover the Hessian, 
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‘ lsq’ applies a least-square gradient calculation twice. First it computes 
gradients via least-squares. Then the Hessian is computed by a second 
application of least-squares to the reconstructed gradient. 

‘ green ’ use a Green variational approach, see Loseillc et at. [47] for 
details. 

‘ kexact ’ reconstructs the Hessian with a k-exact approach. See Barth 
[48] for details. 

'grach is volume- averaged element-based gradients, applied twice. 

'mesh’ implies the metric of the current grid for use in testing grid 
adaptation mechanics or maintaining the current anisotropy. 

adapt unax_anisotropy = 1.0e6 

This is the upper limit of the largest to smallest spacing in the metric, 
adapt _max_edge .growth = 2.0 

This is the amount of coarsening that will be allowed by the scalar term 
of feature-based adaptation. It is not used by adjoint-based adaptation. 

adapt_max_edge_length = -1.0 

This sets a maximum allowable spacing of the metric. It is a grid and 
problem dependent value and should be expressed in grid units. A neg- 
ative value is unlimited. 

adapt_min_edge_length = -1.0 

This sets a minimum allowable spacing of the metric. It is a grid/problem 
dependent value and should be expressed in grid units. A negative value 
is unlimited. 

adapt_output_tolerance = -0.5 

This is the error request for output-based adaptation and the scaling of 
the scalar term for feature-based adaptation. Feature-based adaptation 
requires a positive number. Output-based adaptation can be negative 
to indicate a relative error reduction or positive to indicate an absolute 
error request. It is difficult to choose a good value for this tolerance, see 
adaptwcomplexity for a more intuitive way to request the adapted grid 
size. 

adapt_complexity = -1.0 

This is the target complexity for the metric. It is intended to allow a 
user specification of the number of nodes in the adapted grid. There is 
a difference between the requested complexity and the number of nodes 
in the adapted grid that is a function of grid size. This is because the 
requested complexity is a continuous measure, but the metric is discrete. 
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Also, the adaptation mechanics produce a grid that is near but does not 
exactly match the metric. Adjust the requested complexity manually to 
obtain the desired grid size if the grid is smaller or larger than expected. 

adapt .gradation = -1.0 

This is the allowable gradation of spacing between adjacent metric ten- 
sors. [49] A positive value activates gradation control, which should have 
parameter in the range [1.1 — 2.0]. A negative value deactivates this 
option. A smaller value producing a more gradual spatial variation of 
the spacing request (1.0 would be no variation). 

adapt_error_estiraation = ’embed’ 

This selects the method used for error estimation for output-based adap- 
tation, 

' embed ’ uses a uniformly refined grid and interpolated solution to esti- 
mate the output error. [50] 

'single’ uses the current grid and reconstructed solution to estimate 
the output error. Uses much less memory, but does not provide an 
improved estimate of the functional. [28] 

'opt-goal’ is the optimal goal-oriented metric. [51] It requires the 
namelist option adapt.complexity to be set. 

adapt .exponent = 0.2 

This is the exponent on error estimate to map local error to a change 
in grid spacing. It is based on an a priori spatial error convergence 
estimate. [50] 

adapt_f eature_scalar_key = ’density’ 

This is the “key” flow variable (feature) on which to adapt for feature- 
based adaptation, 

' mach ’ is Mach number. 

'pressure’ is pressure. 

' entropy ’ is entropy. 

'temp’ is temperature. 

'density’ is density. 

' vorticity-magnitude ’ is the magnitude of the vorticity vector. 
adapt.feature_scalar.form = ’delta’ 

This is the method to calculate feature-based refinement indicator from 
the adapt_f eature_scalar_key scalar held. The following terms are 
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computed for each edge in the grid and the nodal adaptation intensity 
is the maximum for all incident edges. The edge terms are, 

' delta’ is the jump in the key across the edge. 

' delta-1’ is the jump the key across the edge times the edge length to 
the adapt_f eature_length_exp power. 

'average-1’ is the average key of the two nodes of an edge times the 
edge length. 

' ratio ’ is the ratio of the largest to the smallest key at the edge nodes, 
'max’ is the largest key at the nodes of the edge. 

' none ’ will not use scalar term. It is uses the Hessian only, 
adaptxf eature_length_exp = 0.5 

This is the exponent for use with adapt_f eature_scalar_f orm = ’ delta-1 ’ . 
adapt_intersect unetric_in_time = .false. 

This will export a metric intersected over a window that includes each 
time step of the current run. It is used for fixed-point adaptation of 
time- accurate simulations. [51] 

adapt unetric_from_f ile = ’ ’ 

This reads the metric from this hie instead of computing it when it is 
blank. 

adapt_export unetric = .false. 

This exports the metric for external grid adaptation tools. 
adapt_twod = .false. 

When .true., compute a 2D metric for a one cell wide 3D grid. This 
is required when a 2D adaptation method is selected but the grid is 
actually a one cell wide 3D grid, because the adjoint does not have a 2D 
specific mode. 

adaptrverbose = .false. 

When .true., this option reports more information during the error es- 
timation process. 

adapt _export_f eature_scalar_key = ’none’ 

This is the format to export the feature scalar key for visualization, 

'none’ will not export. 

' cgns ’ is CGNS format, requires Fun3D to be configured with a CGNS 
library. This format already includes x, y, and z. Set these variables to 
.false, to avoid duplication. 
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'f vims’ is FieldView C-binary (Fortran stream) format. This format 
already includes x, y, and z. Set these variables to .false, to avoid 
duplication. 

'VTK’ is legacy VTK format. 

' csv’ is a comma separated value format. 

'tec’ is a single image ASCII tecplot format. 

'raw_ascii’ is a single image raw ASCII space separated format 
adapt_visualize_metric = ’none’ 

This is the format to export the metric for visualization, 

'none’ will not export. 

' cgns ’ is CGNS format, requires Fun 3D to be configured with a CGNS 
library. This format already includes x, y, and z. Set these variables to 
.false, to avoid duplication. 

'fvuns’ is FieldView C-binary (Fortran stream) format. This format 
already includes x, y, and z. Set these variables to .false, to avoid 
duplication. 

'VTK’ is legacy VTK format. 

'csv’ is a comma separated value format. 

'tec’ is a single image ASCII tecplot format. 

'raw.ascii’ is a single image raw ASCII space separated format, 
adapt .current _h_method = ’edge’ 

This is the method to estimate the current spacing of the grid, 

' edge ’ will use the shortest incident edge at a node. 

'implied’ will use the largest eigenvalue of adjacent element implied 
metrics. 

adapt _current _h_gradat ion = 1.5 

This limits the gradation of the current spacing estimate by requiring it 
to be larger than this ratio of its neighbor’s spacing estimate. 
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B.4.31 &adapt mechanics 

This namelist contains variables that control how grid adaptation is per- 
formed. More details on general metric-based grid adaptation can be ob- 
tained in section 7. This namelist also contains variables to control specialized 
line adaptation adapt.library = ’line' and shock fitting line adaptation 
adapt.library = ’ sflineU 

Variables with the ladapt_ prefix control line adaptation and variables 
with a sf line, prefix control shock fitting line adaptation. These specialized 
ID adaptation methods originated in the LAURA code and have a number of 
requirements that are described in the LAURA User’s Manual. [52] The grid 
origin must be structured and all nodes assigned to a unique line. All lines 
must have the same number of nodes. The outer boundary (opposite solid 
walls) can be moved in or out to align with a developing bow shock and the 
distribution of points across the boundary layer can be adjusted to recover a 
target cell Reynolds number. If the grid has prisms grown off a solid surfaces 
then the distribution of prism heights can be adjusted to recover a target cell 
Reynolds number at the wall while retaining the the original spacing at the 
top of the prism stack. 

Variable names beginning with sfline. control how shock fitting meshes 
are adapted. Currently the shock fitting is only available with line adaptation 
which is engaged by specifying adapt.library = 5 sflineU The variables 
ladapt_re_cell, ladapt.epCLgrd, ladapt_fstr, and ladapt_g_limiter are 
also active with shock fitting. 


feadapt .mechanics 


adapt.library 

= 

' refine 

adapt.project 

= 

1 1 

adapt _f reezebl 

= 

-1.0 

adapt.cycles 


2 

adapt _bamg_ command 

- 

' bamg 1 

adapt _bamg_geometry_f ormat 

= 

' amdba ' 

ladapt.f sh 

= 

0.8 

ladapt.f str 

= 

0.75 

ladapt.f ctr jmp 

= 

1.05 

ladapt_re_cell 

= 

1. 

ladapt_beta_grd 

= 

0. 

ladapt_epO_grd 

= 

0. 

ladapt.max.di stance 

- 

l.e+06 

ladapt.jumpf lag 

- 

2 

ladapt.f req 

= 

0 

1 adapt _max 

= 

1000 

ladapt_g_limiter 

= 

0. 

sf adapt _f sbuf f r 

= 

3 

sf adapt _ceqinc 

= 

0.5 
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sf adapt _shkdtct 
sf adapt _f sf racO 
sf adapt _f sf raci 


= l.Oe-Ol 
= l.Oe+OO 
= l.Oe-Ol 


adapt ^library = ’ refine/one ’ 

Adaptation library to call. The options are, 

‘ refine/one ’ is the refine tetrahedral metric-based adaptation library. 
See Park [28] for a detailed description. 

‘refine/two’ is a version of the refine adaptation library that is still 
undergoing development. It is based on original version of refine with 
some ideas from Michal and Krakos. [53] 

‘meshsim’ is the Simmetrix MeshSim M adaptation library. 

‘ bamg ’ is the B AMG [4] 2D metric-based adaptation library. The metric 
and solution files will be exported and the BAMG executable will be run 
in the ../Flow directory. 

'line’ is line-based adaptation [52] for structured grids. 

‘ sfline’ is shock-fitting line-based adaptation for structured grids. 

‘ interpolate’ will linearly interpolate the project_rootname solution 
to an existing adapt_project grid without adaptation using the ap- 
proach of Shenoy. [54] 

adapt_project = ’ ’ 

This is the project name for exporting the adapted grid and solution. An 
empty string appends _R to the project_rootname from the feproject 
namelist. 

adaptxfreezebl = -1.0 

This prevents modification of the grid within this distance of solid wall 
boundaries. It is used to to preserve an existing boundary layer grid 
structure. A negative value does not freeze. It is described by Park and 
Carlson. [55] 

adapt_cycles = 2 

This is the number of adaptation passes. It is only used for adapt.library 
= ’ \ref ine/ one ’ . Choosing more cycles will produce a grid that better 
matches the metric, but can increase the time required for adaptation. 

adapt _bamg_command = ’bamg’ 

This the the system command to execute BAMG. It may include the full 
path or command line arguments. 
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adapt _bamg_geometry .format = ’ amdba’ 

BAMG geometry file format 

‘amdba’ specifies -b [project_rootname] .ambda as the BAMG geome- 
try source. This will spline current boundary nodes to form the geometry 
of the domain boundary. It is approximate, but less likely to fail than 
.msh hie boundary reconstruction. 

'rash’ specifies -b [project_rootname] .msh as the BAMG geometry 
source. This will access the original geometry .msh hie to define the 
domain boundary, but BAMG may have problems with boundary recon- 
struction. 

ladapt_fsh = 0.8 

This is the fraction of the distance between the body and the opposing 
boundary along a line of nodes where the captured shock is situated. 

ladapt_fstr = 0.75 

This is the fraction of edges along a line that are intended to resolve the 
boundary layer. 

ladapt_f ctrjmp = 1.05 

This is the property ratio used to detect the shock when marching from 
the freestream toward the body. It is assumed the how above the shock 
is uniform and the property ratios across edges along the line remain 
equal to one until the shock is encountered. 

ladapt_re_cell = 1. 

This is the target cell Reynolds number based on the speed of sound 
used to define the edge length An of the hrst edge leaving the wall. 
re ce u = pAnc/ji. 

1 adapt _beta_grd = 0. 

This is an exponential grid distribution parameter. Any value greater 
than 1 will override adaptation. If it is used to override adaptation to 
local how, the recommended value is 1.15. 

Iadapt_ep0_grd = 0. 

This is a grid clustering factor to pull nodes into the captured shock. 
A minimum value of 0 produces no clustering. A maximum value of 
6.25 produces greatest clustering. Larger values can produce negative 
volumes. 

ladapt_max_distance = l.e+06 

This is the maximum distance in grid units the outer boundary can be 
moved away from the body. This parameter is useful when adapting to 
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the shock in the wake, where the adapting grid may become excessively 
skewed. This value then effectively defines the maximum length of the 
wake domain. 

1 adapt _jumpf lag = 2 

This is an integer flag used to select the method of shock detection, 

‘O' is no movement of outer boundary. Resolution in the boundary layer 
is adjusted to recover target re_cell. 

‘ 1 ’ uses pressure as sensing parameter. 

‘ 2 J uses density as sensing parameter. 

‘ 3 J uses temperature as sensing parameter. 

‘ 4 ’ scales all edges along the line by a factor equal to ladapt_f ctr jmp. 
ladapt_freq = 0 

This is the number of relaxation steps between calls to line adaptation. 
The value 0 prevents line adaptation. 

ladaptnnax = 1000 

This is the maximum number of calls to line adaptation permitted. 
ladapt_g_limiter = 0. 

This parameter insures a minimum mesh size does not get too big on a 
line and cause local skewing. It must be a positive number to engage. 

sf adapt _fsbuffr = 3 

This is the number of buffer nodes between the freestream boundary and 
the fitted shock. Zero buffer nodes make the freestream boundary the 
shock fitting surface, three buffer nodes moves the shock fitting surface 
three nodes into the interior of the computational domain relative to the 
freestream boundary. 

sf adapt_ceqinc = 0.5 

This is the shock fitting compatibility equation influence coefficient. A 
value of 0.0 means that shock fitting is controlled by the continuity equal 
to the compatibility equation, a value of 1.0 means that the shock fitting 
is controlled by momentum equation compatibility equal to the compat- 
ibility equation, and a value of 0.5 means that shock fitting is equally 
controlled by the continuity and momentum compatibility equations. 

sf adapt_shkdtct = 1.0e-01 

This is the shock fitting shock-boundary interaction detector coefficient. 
This parameter controls when the shock is considered to be interacting 
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with the shock fitting boundary nodes and determines when the bound- 
ary begins to be fitted to the shock. The value is one minus the local 
relative density jump below which the shock is not considered to be in- 
teracting with the boundary. Increasing this parameter decreases the 
sensitivity of the sensor and decreasing this parameter increases the sen- 
sitivity of the sensor. 

sf adapt_f sfracO = 1.0e+00 

This is the shock fitting initial freestream velocity boundary velocity frac- 
tion. When the bow shock has not yet reached the freestream boundary, 
the shock fitting equations are not valid. However, the code allows the 
freestream boundary to initially move towards the body at some fraction 
of the freestream boundary velocity. A value of 0.0 freezes the freestream 
boundary until the shock reaches it, a value of 1.0 moves the freestream 
boundary at the freestream velocity until the shock reaches it, and a 
value in the range (0.0, 1.0) moves the freestream boundary towards the 
body at sf adapt_f sfracO*freestreamtotal velocity. 

sf adapt_f sfraci = 1.0e-01 

This is the shock fitting interaction freestream velocity boundary veloc- 
ity fraction. When the bow shock has been determined to be interact- 
ing with the freestream boundary, the shock fitting equations are not 
valid all along the shock. However, the code allows the initial interac- 
tion speed of the shock with the freestream boundary to be scaled back 
at some fraction of the freestream boundary and/or shock velocity. A 
value of 0.1 constrains the freestream boundary to move at a fraction 
of the freestream velocity and a value in the range (0.0, 1.0) moves the 
freestream boundary towards/away from the body at freestream total 
velocity* sf adapt _f sf rac i . 
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B.4.32 &massoud output 

This namelist controls the output of hies for interaction with the MDO pack- 
ages (e.g., design, aeroelastics) . In a design setting, these hies contain the 
information necessary to parameterize the surface grid(s). The command- 
line option --write_aero_loads_to_f ile is required to output the aeroelas- 
tics hie [projectvrootname] _ddfdrive_bodyN.dat and the command line op- 
tion --write_massoud_f ile is required to output the design parameterization 
hie [project_rootnamej_rnassoud_bodyN.dat for each of the N body groups 
present. 

&massoud_output 


n_bodies 

= 

0 




nbndry ( : ) 

= 

0 




boundary_list ( : ) 

= 

1 1 




massoud_output_f req 

= 

-1 




massoud_f ile_f ormat 

= 

' ascii ' 



massoud_use_initial_coords 

= 

. false . 



aero_loads_output_f req 

= 

-1 




aero_loads_f ile_f ormat 

= 

' ascii ' 



include_time_inf o 

= 

. true . 



aero_loads_use_initial_coords 

= 

. false . 



aero_loads_dynamic_pressure 

= 

1.0 




output_transf orm(l ,1:4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

output_transf orm(2, 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

output_transf orm(3, 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

output_transf orm(4, 1 : 4) 

= 

0.0, 

0.0, 

0.0, 

1.0 

output _scale_f actor 

= 

1.0 




input_transf orm(l ,1:4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

input_transf orm(2 , 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

input_transf orm(3 , 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

input_transf orm(4, 1 :4) 

= 

0.0, 

0.0, 

0.0, 

1.0 

input _scale_f actor 

= 

1.0 





/ 


nibodies = 0 

This is the number of user-defined bodies. For moving-grid cases, these 
bodies are typically the same as those defined as moving bodies, but that 
need not be the case. 

nbndry ( : ) =0 

This is the number of boundary patches listed for a given body, 
boundary.list ( : ) = ’’ 

This is a list of boundary patch numbers for a given body. Commas and 
dashes can be used to specify ranges, i.e., ’1,2, 5-7 J . 
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massoud_output_freq = -1 

This is the iteration frequency of massoud output, where the special 
value -1 corresponds to once at the end of a successful run. 

massoud_f ile_f orraat = ’ ascii ’ 

This is the format of the massoud hie; the alternate choice is ’ stream’ 
(C binary). 

'ascii’ is ASCII hie format 

'stream’ is Fortran stream (C binary) format 

massoud_use_initial_coords = .false. 

Write the massoud hie for the x,y,z surface coordinates at t=0. Other- 
wise, use current x, y, z surface coordinates. 

aero_loads_output_freq = -1 

This is the iteration frequency of aerodynamic loads output, where the 
special value -1 corresponds to once at the end of a successful run. 

aero_loads_f ile_f ormat = ’ascii’ 

This is the format of the aerodynamic loads hie; the alternate choice is 
’stream’ (C binary). 

'ascii’ is ASCII hie format 

'stream’ is Fortran stream (C binary) format 

include_time_inf o = .true. 

Write simulation time and strand info to ASCII Tecplot M hle(s). Includ- 
ing time info in the hies makes animation within Tecplot lM very simple. 

aero_loads_use_initial_coords = .false. 

Write the current aerodynamic loads mapped to the x, y, z surface coor- 
dinates at t=0. Otherwise, use current x, y, z surface coordinates. This 
option is only relevant if the grid is moved or changed during the solution 
process. 

aero_loads_dynamic_pressure = 1.0 

The dynamic pressure used to convert force coefficients into forces; the 
default value leaves the output in coefficient form. Note that the input 
variable output _scale_f actor separately handles scaling of coordinate 
values, so care must be exercised to insure appropriate dimensional forces 
if both are used in combination. 
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output.transf orm(l , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow output of aero loads 
in a custom coordinate system; typically used to output aero loads in 
an FEM/CSD coordinate system that differs from the CFD coordinate 
system. Note, at this point in time, this transform is applied to ALL 
bodies that are defined in this namelist. Note: the transform matrix 
should NOT include a scaling factor (e.g. inches to meters); any required 
scale factor is input separately. 

output_scale_f actor = 1.0 

Allows a scaling of the output x,y,z coordinates (e.g. meters to inches). 
Scaling is applied as a multiplicative factor. 

input_transf orm(l , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow input of a new surface 
mesh that is defined in a custom coordinate system; typically used to 
read in a displaced surface defined in an FEM/CSD coordinate for use in 
the CFD coordinate system. Note, at this point in time, this transform 
is applied to ALL bodies that are defined in this namelist. Note: the 
transform matrix should NOT include a scaling factor (e.g. inches to 
meters); any required scale factor is input separately. 

input_scale_f actor = 1.0 

Allows a scaling of the input x,y,z coordinates (e.g. inches to meters). 
Scaling is applied as a multiplicative factor. 
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B.4.33 &sonic boom 


This namelist specifies how near-field pressures are extracted from Fun 3D 
for comparison to wind tunnel measurements, atmospheric propagation to the 
ground by another code, or for boom related adjoint cost functions. When 
nsignals is greater than zero, the pressure signature is output as a Tecplot™ 
file. The number of points in this output file is determined by the number of 
element faces intersected by each user-specified ray, and will span the x-extent 
of the entire mesh at that ray location. 

The rays are rotated about (x_cor,z_cor) by angle.of .attack when the 
variable rotate_ray_by_angle_of .attack is true. 

This namelist is also used with the sonic boom adjoint cost functions 
boom.targ (section 8.2.6) and sboom (section 8.2.7). To form the cost func- 
tion the ../rubber. data file is required for the flow and adjoint solvers. See 
section 6.3 for details on the minimum inputs required for specifying the ad- 
joint cost function. To compute the value of the objective function in the flow 
solver, the — design_run command line option is required. 


&sonic_boom 



nsignals 

= 

0 

y_ray ( : ) 

= 

0.001 

z_ray ( : ) 

= 

0.0 

x_cor 

= 

0.0 

z_cor 

= 

0.0 

rotate_ray_by_angle_of _attack 

= 

. true . 

npoints 

= 

1000 

ray_x_limit .method 

= 

' local 

x_lower_bound 

= 

-1 . e20 

x_upper_bound 

= 

1 . e20 

dp.pinf 

= 

. true . 

p.pinf 

= 

. false 

weight 

= 

. false 


/ 


nsignals = 0 

This is the total number of signal rays. 
y_ray(:) = 0.001 

This is the y value of each ray before angle.of .attack rotation. It is 
dimensioned 1 to nsignals. 

z_ray(:) = 0.0 

This is the z value of each ray before angle.of .attack rotation. It is 
dimensioned 1 to nsignals. 
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x_cor = 0.0 

This is the x center of angle.of .attack rotation. 
z.cor = 0.0 

This is the z center of angle.of .attack rotation 
rotate_ray .by .angle.of .attack = .true. 

When .true., this will rotate the rays by angle.of .attack about x.cor 
and z.cor. 
npoints = 1000 

This is the nominal number of points in each ray that is used to construct 
the cost function. Any points lying outside the domain will be ignored. 
The points are linearly spaced between the lower and upper bound of x. 

ray_x_limit .method = ’local’ 

This is the method used to determine the ^-direction start and end of 
the ray when forming the objective function. If x.lower.bound and/or 
x.upper.bound is specified, then ray_x_limit .method must be set to 
’explicit’. 

‘ local’ sets each ray limit independently by computing the x min and 
x max of all grid cells intersected by the ray. 

'explicit’ explicitly sets the x min and x max of all rays with the 
x.lower.bound and x.upper.bound namelist variables. Only valid for 
adjoint cost function boora.targ. 

x.lower.bound = -l.e20 

This is the explicit x lower bound for ray_x_limit_method= ’ explicit ’ 
in the cost function definition, 
x.upper.bound = l.e20 

This is the explicit x upper bound for ray_x_limit _method= ’ explicit ’ 
in the cost function definition, 
dp.pinf = .true. 

When .true., this will include normalized delta pressure (p — Poo)/Poo in 
tecplot output. 

p.pinf = .false. 

When .true., this will include normalized pressure (p)/poo in tecplot 
output. 

weight = .false. 

When .true., this will include a weight of one in tecplot output for use 
in setting up a near-body target pressure design. 
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B.4.34 fesboom 


This namelist contains variables that specify the inputs required to execute 
the sBOOM library. See section 8.2.7 for details. 


fesboom 

alt 

- 

45000.0 

h g 

= 

0.0 

headangle 

= 

0.0 

climbangle 

= 

0.0 

dmdt 

= 

0.0 

turnrate 

= 

0.0 

climbrate 

= 

0.0 

rs 

= 

500.0 

signum 

= 

10000 

zeronum 

= 

1200 

tol2 

= 

l.e-6 

nonlinear 

= 

1 

thermoviscous 

= 

1 

relaxation 

= 

1 

initialtimestep 

= 

0.01 

ref 1 

= 

1.9 

outf lag 

= 

0 

numouts 

= 

1000 

tol 

= 

0.005 

input ininches 

= 

0 

adjmode 

= 

1 

runmode 

= 

1 

objmode 

= 

1 

nazimuths 

= 

1 

phi ( : ) 

= 

0.0 

targetdbas ( : ) 

= 

56.0 

createtarget 

= 

0 

lowerbound 

= 

-1000.0 

upperbound 

= 

-1000.0 

lappass 

= 

500 

target_numpts ( : ) 

= 

0 

target_xx( : , : ) 

= 

0.0 

target_dpress ( : , 

:) = 

0.0 

tf lag 

= 

0 

ntalt 

= 

0 

ztalt ( : ) 

= 

0.0 

talt ( : ) 

= 

0.0 

windf lag 

= 

0 

nwindx 

= 

0 

zwindx( : ) 

= 

0.0 
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windx( : ) 

= 

0.0 

nwindy 

= 

0 

zwindy ( : ) 

= 

0.0 

windy ( : ) 

= 

0.0 

rf lag 

= 

0 

nhalt 

= 

0 

zrh( : ) 

= 

0.0 

rh( : ) 

= 

0.0 

bodylen 

= 

127.0 

reg 

= 

1 

CD 

T - 1 

regr 

= 

1 

CD 

T — 1 

lbd 

= 

0.99 

ubd 

= 

1.0 


alt = 45000.0 

This is the cruise altitude of the full-scale vehicle in feet. 
hg = 0.0 

This is the height of the ground in feet, 
headangle = 0.0 

This is the vehicle heading angle in degrees. A 180 heading would mean 
away from the x-axis, a 90 heading would mean away from the y- axis. 
This option is only relevant when winds are specified. 

climbangle = 0.0 

The is the vehicle climb angle in degrees. 

dmdt = 0.0 

This is the acceleration of the vehicle in 1/second (Mach number per 
second) . 

turnrate = 0.0 

This is the turning rate of the vehicle in degrees per second. 

climbrate = 0.0 

This is the climb rate of the vehicle in degrees per second. 

rs = 500.0 

This is the off-body distance in full-scale feet. This full-scale distance 
should match the location in grid units used to define y_ray and z_ray 
in &sonic_boom. 
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signum = 10000 

This is the number of points representing the off-body waveform for prop- 
agation. Increasing the number points reduces the discretization error 
of the Burgers equation and increase the execution time of sBOOM. 

zeronum = 1200 

This in the number of points used to zero pad the front part of the 
signature. These points are required to prevent the initial shock from 
propagating to the front of the Burgers equation domain and causing 
a numerical instability. The actual waveform will be sampled using 
(signum-zeronum) points. Typically, 10-20% of signum is required. 

tol2 = l.e-6 

This is the leading zero tolerance of the input waveform. It is used to 
truncate the initial portion of the off-body waveform before zero padding, 
where dp/p value are less than this number. 

nonlinear = 1 

This controls solution non-linearity, 

‘ 1 J uses cumulative non-linearity. 

‘ 0 J does not use cumulative non-linearity. 
thermoviscous = 1 

This controls the modeling of thermo-viscous absorption, 

‘ 1 ’ uses cumulative thermo-viscous absorption. 

‘ 0 J does not use thermo- viscous absorption. 

relaxation = 1 

This controls the modeling of molecular relaxation, 

‘ 1 ’ uses cumulative molecular relaxation. 

‘ 0 J does not use molecular relaxation. 

initialtimestep = 0.01 

Nondimensional initial step size for propagation. A smaller number pre- 
vents a multi-valued function, but increases execution time. If you re- 
ceive a discontinuity error, reduce this value. 

ref 1 = 1.9 

This is the ground reflection factor used to scale ground signatures. 

outflag = 0 

This determines the format of the output, 
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‘ 0 ’ outputs delta pressure in psf as a function of time in ms. 

‘ 1 J outputs delta pressure divided by freestream pressure as a function 
of x in feet. 

numouts = 1000 

This is the number of points requested in the ground signature. 
tol = 0.005 

This is the slope tolerance needed for removing zero paddings from the 
ground signatures. This allows signatures at different azimuthal angles 
to have the same time axis starting with the initial shock. 

inputininches = 0 

This is the units of the Fun 3D grid and geometry to scale the near field 
signature x for propagation, 

f 0’ for Fun 3D grid units in feet. 

‘ 1 ’ for Fun 3D grid units in inches. 

‘ 2 ’ for Fun 3D grid units in meters. 

ad j mode = 1 

This is the sBOOM simulation mode, 

‘ 1 J for a primal and adjoint simulation. 

‘ 0 J for primal simulation only. 

runmode = 1 

This is the type of propagation and the class of cost function, 

‘ 1’ propagates near field dp/p ^ to ground and adjoint sensitivities of 
ground based metrics defined by objmode. The target pressure is speci- 
fied with target_numpts, target.dpress, and target_xx. 

‘O’ reverse propagates near field dp/p^ to compute equivalent area 
(when rs< (alt— hg)) and directly converts off-body pressures to equiv- 
alent area (when rs> (alt— hg)). No ground signature or ground-based 
cost function is computed. See bodylen, reg, regr, lbd, and ubd. The 
target area distribution is specified with target_numpts, target.dpress, 
and targetvxx. 

objmode = 1 

This is the cost function definition. The value of runmode changes its 
behavior as follows, 
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‘ 1 ’ for an A-weighted loudness target of I = ( dBA — dBA t ) 2 when 
runmode=l and an equivalent area target / = Y^iLi ^[Ae(i) — Ae t arget(i)} 2 

when runmode=0. 

‘2’ for an inverse pressure design objective of I = Y^iLilP^) ~ p(M)] 2 
when runmode=l and an equivalent area sum / = JA =1 Ae(i) 2 when 

runmode=0. 

‘ 3 J for combined A-weighted loudness and inverse pressure design ob- 
jective of I = ( dBA — 56. 0) 2 + YliLi [p(*) — pit A)} 2 when runmode=l. 

‘4’ for an A-weighted loudness objective of I = dBA when runraode=l. 
nazimuths = 1 

This is the number of azimuths to propagate. The nazimuths must 
match nsignals in &sonic_boom. 

phi ( : ) = 0.0 

This is a nazimuths length vector of azimuthal locations in degrees, 
targetdbas ( : ) = 56.0 

This is the target (dBAt) at each azimuthal location when objmode=l. 
createtarget = 0 

This is the source of a ground target signature, 

‘ 0 J for no ground target signature. 

‘ 1 J to internally create a ground target by Laplace smoothing. The 
smoothing is controlled by lowerbound, upperbound, and lappass. 

‘ 2 J for a user specified target. The target is defined by the targetmumpts, 
target_xx, and target_dpress variables. 

lowerbound = -1000.0 

When createtarget=l, this is the lower bound in time (milliseconds) 
after which the user wants to Laplace smooth the computed signature 
to form the target. When runmode=0, this defines the start of locations 
in X (feet) where any difference in equivalent area between actual and 
target equivalent areas will contribute to the cost functional. Outside 
these bounds, even if the equivalent area does not match the target, it 
does not contribute to the cost functional. 

upperbound = -1000.0 

When createtarget=l, this is the upper bound in time (milliseconds) 
before which the user wants to Laplace smooth the computed signature 
to form the target. When runmode=0, this defines the end of locations 
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in X (feet) where any difference in equivalent area between actual and 
target equivalent areas will contribute to the cost functional. Outside 
these bounds, even if the equivalent area does not match the target, it 
does not contribute to the cost functional. 

lappass = 500 

The number of Laplace smoothing passes to generate a target ground 
signature. A higher number increases the smoothness of the target. It 
is only used for createtarget=l. 

target_numpts ( : ) = 0 

This is the number of points in the target_xx and target_dpress at 
each azimuth. It is used for runmode=l with objraode=2,3 or runmode=0 
with objmode=l. 

target _xx( ) = 0.0 

This is the time (in milliseconds) of the target signature at each azimuth 
for runmode =1 or x in feet for runmode=0. It is only used for some 
objective functions, see objmode. The first index is azimuthal location 
and the second index is the target signature point. 

target_dpress ( : , : ) = 0.0 

This is the delta pressure (in psf) of the target signature at each az- 
imuth for runmode=l or the equivalent area target for runmode=0. It is 
only used for some objective functions, see objmode. The first index is 
azimuthal location and the second index is the target signature point. 

tflag = 0 

This controls the source for the atmospheric temperature distribution, 
‘0 J for the 1976 U.S. Standard Atmosphere temperature profile. 

1 1 ’ for a temperature profile specified by ntalt, ztalt, and talt. 
ntalt = 0 

This is the number of ztalt altitude and talt temperature pairs to 
define the temperature profile. 

ztalt(:) = 0.0 

This is ntalt length vector of altitudes (in meters) to specify an atmo- 
spheric temperature distribution. 

talt(:) = 0.0 

This is ntalt length vector of temperature (in Fahrenheit) to specify an 
atmospheric temperature distribution. 
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windflag = 0 

This controls the source for winds, 

‘ 0 J for no winds. 

‘ 1 J for a wind prohle specified by nwindx, windx, zwindx, nwindy, 
windy, and zwindy. 

nwindx = 0 

This is the number of zwindx altitude and windx x-wind pairs that define 
the wind prohle. 

zwindx(:) = 0.0 

This is a vector of length nwindx of altitude (in meters) to specify a wind 
prohle. 

windx(:) = 0.0 

This is a vector of length nwindx of x-wind speeds (in meters/sec) to 
specify a wind prohle. 

nwindy = 0 

This is the number of zwindy altitude and windy y-wind pairs that define 
the wind prohle. 

zwindy(:) = 0.0 

This is a vector of length nwindy of altitude (in meters) to specify a wind 
prohle. 

windy(:) = 0.0 

This is a vector of length nwindy of y-wind speeds (in meters/sec) to 
specify a wind prohle. 

rflag = 0 

This controls the source for the atmospheric humidity distribution, 

‘0 J for the 1976 U.S. Standard Atmosphere relative humidity prohle. 

‘ 1 ’ for a relative humidity prohle specihed by nhalt, zrh, and rh. 
nhalt = 0 

This is the number of zrh altitude and rh relative humidity pairs. 
zrh(:) = 0.0 

This is a vector of length nhalt of altitude (in meters) to specify a 
relative humidity prohle. 
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rh( : ) = 0.0 


This is a vector of length nhalt of relative humidity (in percent) to 
specify a relative humidity profile. 

bodylen = 127.0 

This is the aircraft body length in feet. It is only used for the adjoint of 
equivalent area matching, runmode=0 and adjmode=l. 

reg = l.e-4 

This is the thermo- viscous absorption regularization parameter. A smaller 
value could lead to an ill-posed reverse diffusion problem. A higher value 
increases error. Applicable only when rs< (alt— hg). It is only used for 
equivalent area, runmode=0. 

regr = l.e-4 

This is the molecular relaxation regularization parameter. A smaller 
value could lead to an ill-posed reverse diffusion problem. A higher 
value increases error. Applicable only when rs< (alt— hg). It is only 
used for equivalent area, runmode=0. 

lbd = 0.99 

This is the under-deviation parameter for reversed equivalent area match- 
ing. Equivalent area deviations below a target are generally favorable to 
deviations above a target. Equivalent area matching cost functions and 
their sensitivities are only computed when the equivalent area is within 
the lbd and ubd limits. It is only used for the adjoint of equivalent area 
matching, runmode=0 and adjmode=l. 

ubd = 1.0 

This is the over-deviation parameter for reversed equivalent area match- 
ing. Equivalent area deviations below a target are generally favorable to 
deviations above a target. Equivalent area matching cost functions and 
their sensitivities are only computed when the equivalent area is within 
the lbd and ubd limits. It is only used for the adjoint of equivalent area 
matching, runmode=0 and adjmode=l. 
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B.4.35 &equi valent area 

This namelist contains variables that specify the inputs associated with equiv- 
alent area-based sonic boom cost functions, which is described in section 8.2.8. 
The number and order of these inputs should match the equivalent area (Ae) 
functions appearing in ../rubber. data. 

&equivalent_area 


nf unctions 

= 0 

nplane ( : ) 

= 0 

global_scaling_f actor ( : ) 

= 1.0 

lif t_scaling_f actor ( : ) 

= 1.0 

of f _track_angle ( : ) 

= 0.0 

nfunctions = 0 



This is the total number of Ae functions, including functions used as 
objectives and constraints. 

nplane(:) = 0 

This is the total number of cutting planes along x-axis for each Ae func- 
tion. 

global_scaling_f actor (: ) = 1.0 

This is the Ae(x) scaling factor for each Ae function. 

lif t_scaling_f actor (: ) = 1.0 

This is the Lift L(x) scaling factor for each Ae function, 
off _track_angle( : ) = 0.0 

This is the off-track angle in degrees for each Ae function. 
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B.4.36 &press box function 


This namelist contains variables that are required for the pressibox function, 
which is described in section 8.2.9. The namelist requires the ../rubber. data 
hie for the how and adjoint solvers. See section 6.3 for details on the min- 
imum inputs required for specifying the adjoint cost function. To compute 
the functional in the how solver, the --design_run command line option is 
required. 


&press_box_f unction 
integrand_type = 
gid 

xmin = 

xmax = 

ymin = 

ymax = 

zmin = 

zmax = 


0 

1 

-huge(l .0) 
huge (1 . 0) 
-huge(l .0) 
huge (1 . 0) 
-huge(l .0) 
huge (1 . 0) 


/ 


integrand.type = 0 

This integer indicates the functional form. 

‘ 0 J is the volume integral of pressure squared inside the defined box. 

‘ 1 J is the volume integral of ru-momentum inside the defined box. 

‘ 2 J is the volume integral of ^-momentum inside the dehned box. 

‘ 3 ’ is the density at the global node with index gid. Not admissible for 
eqn.type = ’ incompressible J . 

‘ 4 J is the time derivative of pressure at the global node with index gid. 

‘ 5 J is the time derivative of density at the global node with index gid. 
Not admissible for eqn.type = 5 incompressible ’ . 

gid = 1 

This integer is a global grid point index to be used with integrand.type 
= 3-5. 

xmin = -huge (1.0) 

This real value defines the lower bound in the x-direction for the box 
that encloses the volume integral. 

xmax = huge (1.0) 

This real value defines the upper bound in the x-direction for the box 
that encloses the volume integral. 
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ymin = -huge (1.0) 

This real value defines the lower bound in the y-direction for the box 
that encloses the volume integral. 

ymax = huge (1.0) 

This real value defines the upper bound in the y-direction for the box 
that encloses the volume integral. 

zinin = -huge (1.0) 

This real value defines the lower bound in the z-direction for the box 
that encloses the volume integral. 

zmax = huge(l.O) 

This real value defines the upper bound in the z-direction for the box 
that encloses the volume integral. 
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B.4.37 &pstag function 


This namelist contains variables that are required for the pstag function, 
which is described in section 8.2.5. This namelist requires the ../rubber. data 
hie for the flow and adjoint solvers. See section 6.3 for details on the min- 
imum inputs required for specifying the adjoint cost function. To compute 
the functional in the flow solver, the --desigmrun command line option is 
required. 


&pstag_f unction 

slice_orientation = 1 

disk_radius = 1.0 

x_disk_origin = 0.0 

y_disk_origin = 0.0 

z_disk_origin = 0.0 

/ 

slice_orientation = 1 


This integer represents the orientation of the cutting plane. The accept- 
able values are 1 (x-plane), 2 (y-plane), and 3 (z-plane). 

disk_radius = 1.0 

This real value is the radius of the disk over which the function is to be 
evaluated. 

x_disk_origin = 0.0 

This real value is the x-coordinate of the origin of the disk. 
y_disk_origin = 0.0 

This real value is the y-coordinate of the origin of the disk. 
z_disk_origin = 0.0 

This real value is the z-coordinate of the origin of the disk. 
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B.4.38 Especial parameters 


This namelist specifies changes to the discretization to handle elements with 
large face angles. 

&special_parameters 

large_angle_f ix = 'off' 

override_bc_limitation = .false. 

/ 


large_angle_f ix = ’off’ 

Grids with with elements that have adjacent face angles that approach 
180 degrees may result in a sudden onset of not a number (NaN). Grids 
produced by VGRID may contain these elements. 

'off’ uses all elements in viscous flux evaluation. This is a consistent 
viscous discretization. 

‘ on’ neglects viscous fluxes in cells containing angles between adjacent 
faces of 178 degrees or greater. This is an inconsistent discretization, 
but may allow the calculation of a solution on a grid that is not suitable 
for the consistent viscous discretization. 

override_bc_limitation = .false. 

Allow sensitivity analysis for cases with element-based boundary condi- 
tions. Users should contact Fun3D-Support@lists.nasa.gov to deter- 
mine if this option can be used for their simulation. 
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B.4.39 &vortex generator 

This namelist is used to specify parameters related to source terms designed 
to simulate the effects of vortex generators. 

&vortex_generator 
number_of _vgs 
configuration ( : ) 
boundary_patchl ( : ) 
boundary _patch2 ( : ) 
planf orm_area( : ) 
height (: ) 

calibration_constant ( : ) 
pointl_xcoord( : ) 
pointl_ycoord( : ) 
pointl_zcoord( : ) 
point2_xcoord( : ) 
point2_ycoord( : ) 
point2_zcoord( : ) 
point3_xcoord( : ) 
point3_ycoord( : ) 
point3_zcoord( : ) 
reverse_t ( : ) 
reverse_n( : ) 

/ 

number _of_vgs = 0 
Specifies the number of user-defined vortex generators (max 1000). 

conf iguration( : ) = ’ area_and_height ’ 

Specifies the input configuration for each vortex generator. If config- 
uration^) is ’ area_and Jieight ' , then the ith vortex generator planform 
will be a symmetric trapezoid with the endpoints of its base defined by 
the point 1 and point2 coordinate inputs in the namelist and its area 
and height defined by the planform_area(i)and height(i) values. If con- 
figuration^) is 'three points’, then the ith vortex generator will have a 
triangular planform where the user must supply the coordinates of a 
third point defining the off-surface tip of the vortex generator geometry. 
In this case, the planform area and height are derived quantities based 
on the three input point locations. 

boundary.patchl ( : ) =0 

Specifies the boundary patch index for pointl of the ith vortex generator. 
This patch will be used for projection of the pointl coordinates specified. 


= 0 

= 1 area_and_height 1 
= 0 
= 0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= .false. 

= .false. 
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boundary_patch2 ( : ) = 0 

Specifies the boundary patch index for point2 of the ith vortex generator. 
This patch will be used for projection of the point2 coordinates specified. 

planf orm_area( : ) = 0.0 

Specifies the intended planform area of the ith vortex generator. This 
input only required if configuration = ’area_and_height’. 

height(:) = 0.0 

Specifies the height of the ith vortex generator. This input only required 
if configuration = ’area and height'. 

calibration_constant ( : ) = 0.0 

Specifies the calibration constant of the ith vortex generator. 

pointl_xcoord( : ) = 0.0 

Specifies the x-coordinate of point 1 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

pointl_ycoord( : ) = 0.0 

Specifies the y-coordinate of point 1 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

pointl_zcoord( : ) = 0.0 

Specifies the z-coordinate of point 1 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

point2_xcoord( : ) = 0.0 

Specifies the x-coordinate of point 2 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary _patch2(i). 

point2_ycoord( : ) = 0.0 

Specifies the y-coordinate of point 2 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary _patch2(i). 

point2_zcoord( : ) = 0.0 

Specifies the z-coordinate of point 2 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary _patch2(i). 
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point3_xcoord( : ) = 0.0 

Specifies the x-coordinate of point 3 defining the ith vortex generator 
location. This input only required if configuration = ’three points’. 

point3_ycoord( : ) = 0.0 

Specifies the y-coordinate of point 3 defining the ith vortex generator 
location. This input only required if configuration = ’three .points’. 

point3_zcoord( : ) = 0.0 

Specifies the z-coordinate of point 3 defining the ith vortex generator 
location. This input only required if configuration = ’three points’. 

reverse_t(:) = .false. 

Reverse the assumed direction of the unit vector t for the ith vortex 
generator. 

reverse_n(:) = .false. 

Reverse the assumed direction of the unit vector n for the ith vortex 
generator. 

Additional information on the use of vortex generator source terms 

The implementation of these source terms in Fun 3D is based on the heuristic 
model described in [56] and previous references cited therein. The approach 
avoids the need for resolving geometric details of vortex generator devices 
during mesh generation. Sufficient grid resolution may still be required to 
convect the simulated effects of the vortex generator downstream as desired. 
The user must also provide a calibration constant for each simulated vortex 
generator. This value should be chosen carefully to produce the desired impact 
on the local flowheld. Vortex generator source terms currently may only be 
applied to static grid simulations. The source terms are treated fully implicit 
during the solution procedure. 

After developing the desired set of namelist inputs, it is useful to run the 
solver for a single iteration, requesting boundary output for (at least) the 
boundaries on which vortex generators are to be placed. The geometry for 
each vortex generator as determined by Fun 3D based on the namelist inputs 
will be provided in the Tecplot M hie [project_rootnamej_vg_geometry.dat. 
The user should visualize the placement of each vortex generator in relation 
to the boundary patches of the grid to ensure the desired placement. 

The user will also be provided with a Tecplot™ hie [projectxrootname] 
_vg_vectors.dat. This hie contains the unit vectors b , t, and n according to 
the notation described in [56]. The user should visualize these vectors to ensure 
that they are oriented appropriately. The vector b is defined uniquely by the 
local boundary orientation; however, Fun 3D attempts to infer the directions 
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of the vectors t and n based on the freestream direction. If the local flow 
direction is expected to be substantially different, these vectors may need to 
be manually reversed using the appropriate namelist inputs. 

If desired, the user may also plot the points at which the actual source 
terms will be computed by ‘scatter plotting’ the data contained in the Tec- 
plot™ hie [project_rootnamel_vg_source_locations.dat. These locations 
are determined by the intersections of the vortex generator geometries with 
edges in the grid. Source terms are computed at each of these locations then 
scattered to the residual values at either end of the intersecting edge. 

An example of the geometry features described above and the local howheld 
in the vicinity of simulated trapezoidal and triangular vortex generators near 
the leading edge of a wing is shown here. 




r ho 



Unit vector n 


Figure B4: View of trapezoidal and triangular vortex generators placed near 
the leading edge of a wing geometry. The unit vectors b, t, and n are shown, 
as well as the points where the actual source terms will be computed. 
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B.5 moving body. input 


This namelist file is only used for time-dependent, moving grid cases to specify 
grid motion as a function of time. This file must be used in conjunction with 
either the command line option — moving.grid, or with the input variable 
moving.grid = .true, in the &global namelist of the fun3d.nml input file. 

The grid-motion options in Fun 3D are fairly generally in order to handle 
a wide variety of applications. The basic approach is for the user to define one 
or more boundaries in the grid to be a ‘body’. Multiple bodies may be de- 
fined. Basic setup for these bodies is established using the febody .definitions 
namelist. A hierarchical relation may be established between multiple bodies 
to allow the motion of one body (a ‘child’) to follow the motion of another 
body (the ‘parent’). The top level of this hierarchy is the inertial reference 
frame, and all motion is ultimately referenced back to this inertial frame. Each 
body has its own reference frame, and the reference frames of all bodies are 
assumed to be coincident with the inertial reference frame at t=0. 

Having established the basic body definition(s), the user specifies a general 
descriptor (motion.driver) for the mechanism that will drive the motion of 
the body, and specifies how the mesh is to be moved - by rigid motion or 
by deformation (or both) - in response to the body motion. Note that mesh 
deformation requires more CPU time than rigid mesh motion, and is less ro- 
bust. Mesh deformation may lead to negative cell volumes, at which point the 
solution is terminated, while rigid motion will preserve positive cell volumes. 
Thus, rigid mesh motion should be favored over mesh deformation whenever 
possible. However, there are certain situations where only a deforming mesh 
is appropriate. For example if the body is aeroelastic, then the mesh must be 
deformed to fit the deformed body surface. In some situations the potential 
for a deforming mesh to encounter negative cell volumes can be mitigated by 
combining deformation with rigid motion. An example of this is the motion 
of elastic rotor blades, wherein the overall rotational motion of the blades is 
handled via rigid rotation, but the relatively smaller elastic deflection of the 
blades is handled via deformation. 

The motion.driver specification simply provides a notional mechanism for 
how the body is to be moved; details of this mechanism are then provided by 
one or more additional namelists. For example, if motion.driver = ‘forced’ 
then details of how to move the body, perhaps by rotation with a given fre- 
quency and amplitude, are specified via the &f orced_motion namelist. Other 
options for motion.driver - and the required auxiliary namelists to specify 
the details - are given in the following sections. 

By default, boundary output from Fun 3D for visualization purposes (see 
section 5.3.1) is provided in the inertial frame. It is sometimes useful to have 
this output in a different reference frame, an ‘observer’ frame. For example, 
the observer frame might be one attached to a moving body. Specification of 
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an alternate observer frame is handled via the feobserver anotion namelist. 
See the following sections for descriptions of the namelists in this file. 
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B.5.1 &body definitions 

This namelist specifies which mesh surfaces define the moving bodies. In 
general, each body may have a different motion. However, there are some 
fundamental constraints. For example, in a mesh with multiple bodies under- 
going different motions, either overset meshes or a deforming mesh would be 
required. Note that a deforming mesh might well support only small relative 
motions between the bodies before the mesh becomes invalid (negative cell 
volumes). For a single rigid mesh, all bodies within the mesh would need to 
have the same motion. 

&body_def initions 


n_moving_bodies 

= 

0 

body_frame_f orces 

= 

.false . 

output_transf orm 

= 

.false . 

dimens ional_output 

= 

.false . 

ref .velocity 

= 

1117.0 

ref .density 

= 

0.002378 

ref .length 

= 

1.0 

body .name ( : ) 

= 

1 1 

parent.name ( : ) 

= 

1 1 

n.def ining.bndry ( : ) 

= 

0 

def ining.bndry ( : , : ) 

= 

0 

motion.driver ( : ) 

= 

' none ' 

mesh.movement ( : ) 

= 

' static ' 

x.mc ( : ) 

= 

xmc 

y.mc ( : ) 

= 

ymc 

z.mc ( : ) 

= 

zmc 

s.ref ( : ) 

= 

sref 

c.ref ( : ) 

= 

cref 

b.ref ( : ) 

= 

bref 

move_mc( : ) 

= 

1 

trim.control ( : ) 

= 

' none ' 

baseline.psi ( : ) 

= 

0.0 

steps_per_period( : ) 

= 

0 


/ 

n_moving_bodies = 0 


This is the number of bodies in motion. 
body_frame_f orces = .false. 

This outputs aero forces acting on the body in the frame of the body 
when .true., rather than in the inertial reference frame. 

output .transform = .false. 

This outputs the transform matrix to Transf ormMatrixBody_N.hst for 
body N when .true.. 
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dimensional.output = .false. 


This outputs the body state data (displacements, velocities, and aero 
forces) in dimensional form for forced or 6-DOF motions. Use with 
ref ^velocity, ref_density, and ref_length to produce body state 
output with the desired units. 

refwelocity = 1117.0 

This is the reference velocity to make aerodynamic forces dimensional, 
when dimensional_output = .true. Note that this should correspond 
to the sound speed if compressible. The default corresponds to standard 
sea level speed of sound, in ft/sec. 

ref_density = 0.002378 

This is the reference density to make aerodynamic forces dimensional, 
when dimensional.output = .true. The default corresponds to stan- 
dard sea level density, in slugs/ft 3 . 

ref_length = 1.0 

This is the reference length to make aerodynamic forces dimensional, 
when dimensional_output = .true. The default corresponds to one 
unit consistent with the values of ref.velocity and ref.density (i.e. , 
1 ft for the default reference conditions). 

body_name ( : ) = ’ ’ 

This is the name used to identify the body; the array index corresponds 
to body number. 

parent_name( : ) = ’’ 

This is the name of the parent body; the array index corresponds to body 
number. The motion of a body follows (i.e., is added to) the motion of 
the parent. When naming the parent, ’ ’ signifies that the parent is the 
inertial frame. For single or independently-moving bodies, the default 
parent _name should be used. 

n_def ining_bndry ( : ) = 0 

This is the number of boundaries that define the body; the array index 
corresponds to body number. 

def ining.bndry ( : , : ) = 0 

This is a list of n_def iningJbndry boundaries that define the body; the 
array index 1 corresponds to the boundary (from 1 to n_def iningJbndry) 
defining the body; the array index 2 corresponds to the body number. 
If boundary lumping is used (section B.4.2), the boundaries must corre- 
spond to lumped boundaries. 
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motion.driver ( : ) = ’none’ 

This is the body motion mechanism; the array index corresponds to body 
number: 

' none ’ is for no motion. 

'forced’ uses forced motion prescribed in &f orcedanotion. 

' surf ace_f ile ’ uses surface motion prescribed in &surf aceanotion_f rom_f ile. 

' motion_f ile ’ uses motion prescribed in &motion_from_f ile. 

' 6dof ’ computes motion via 6-DOF library, which is governed by &sixdof anotion. 

' aeroelastic ’ computes motion via &aeroelastic_modal_data, or by 
coupling with an external FEM. 

'custom’ uses custom_kinematics; the user supplies a custom trans- 
form matrix as a function of time and design variables. 

meshanovement ( : ) = ’static’ 

This is the type of grid movement associated with body motion; the 
array index corresponds to body number: 

'static’ no mesh movement. 

' rigid’ rigid mesh movement; all nodes of the mesh rotate/translate in 
unison with the body. 

'deform’ deforms the mesh locally to accommodate the motion of the 
solid body. 

' rigid+def orm’ mesh undergoes both rigid and deforming motions 
xanc ( : ) = xmc 

The is the ^-coordinate of moment center at t — 0; the array index 
corresponds to body number. 

y _mc ( : ) = ymc 

This is the y-coordinate of moment center at t — 0; the array index 
corresponds to body number. 

zanc(:) = zmc 

This is the ^-coordinate of moment center at t — 0; the array index 
corresponds to body number. 

s_ref(:) = sref 

This is the nondimensional reference area for force and moment normal- 
ization; the array index corresponds to body number. 
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c_ref(:) = cref 

This is the nondimensional reference chord length for force and moment 
normalization; the array index corresponds to body number. 

b_ref ( : ) = bref 

This is the nondimensional reference span length for force and moment 
normalization; the array index corresponds to body number. 

movennc(:) = 1 

This controls the movement of the moment center; the array index cor- 
responds to body number. 

‘ 0 ’ leave moment center fixed in space 

‘ 1 : ’ move moment center following the body number indicated by the 
value of move_mc (body) (applicable only for rigid-body motion of body 
movennc(body)) 

trim_control ( : ) = ’none’ 

This controls whether trim as applied to the body; the array index cor- 
responds to body number. 

‘ none ’ no trim control applied; 

‘ design J trim control applied via design variables; 

‘ bodyjnotion J trim control applied via moving body components; 

baseline.psi ( : ) = 0.0 

This is the starting azimuth for trim when trim is used as a design 
variable; the array index corresponds to body number. 

steps_per_period( : ) = 0 

This is the number of steps to define a trim period when trim is used as 
a design variable; the array index corresponds to body number. 
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B.5.2 ^forced motion 


&f orced_motion 


rotate ( : ) 

- 

0 

rotation_rate ( : ) 

= 

0.0 

rotation_f req( : ) 

= 

0.0 

rotation_phase ( : ) 

= 

0.0 

rotation_tphase ( : ) 

= 

0.0 

rotation_amplitude ( : ) 

= 

0.0 

rotation_origin_x( : ) 

= 

0.0 

rotation_origin_y ( : ) 

= 

0.0 

rotation_origin_z( : ) 

= 

0.0 

rotation_vector_x( : ) 

= 

0.0 

rotation_vector_y ( : ) 

= 

1.0 

rotation_vector_z( : ) 

= 

0.0 

rotation_start ( : ) 

= 

0.0 

rotation_duration( : ) 

= 

1 . 0e99 

translate ( : ) 

= 

0 

translation_rate ( : ) 

= 

0.0 

translation_f req( : ) 

= 

0.0 

translation_phase ( : ) 

= 

0.0 

translation_tphase ( : ) 

= 

0.0 

translation_amplitude ( : ) 

= 

0.0 

translation_vector_x( : ) 

= 

0.0 

translation_vector_y ( : ) 

= 

0.0 

translation_vector_z( : ) 

= 

1.0 

translation_start ( : ) 

= 

0.0 

translation_duration( : ) 

= 

1 . 0e99 


rotate(:) = 0 

This is the type of rotational motion; the array index corresponds to 
body number: 

‘ : - 1 ’ rotate to match Cl target 
‘ 0 J for no rotation. 

‘ 1 ’ for constant rotation rate, rotationxrate. 

‘ 2 J is sinusoidal rotation where 6 = rotation.amplitude sin(27r rotation_f req t + 

rotation.phase 7r/ 180) + rotation_tphase 7t/ 180 and t is nondimen- 

sional. 

‘ 3 ’ is a square-wave doublet in rotation 6 = rotation.amplitude for the 
first half of the specified rotation.duration and 6 = -rotation.amplitude 
for the second half of the specified rotation.duration 
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rotation_rate( : ) = 0.0 

This is the nondimensional rotation rate associated with rotate=l; the 
array index corresponds to body number. 

rotation.f req( : ) = 0.0 

This is the nondimensional rotation reduced frequency associated with 
rotate=2; the array index corresponds to body number. 

rotation.phase ( : ) = 0.0 

This is the rotation phase shift (in degrees) associated with rotate=2; 
the array index corresponds to body number. 

rotationvtphase ( : ) = 0.0 

This is the rotation offset (in degrees) associated with rotate=2 or 3; 
the array index corresponds to body number. 

rotation.amplitude ( : ) = 0.0 

This is the rotation amplitude (in degrees) associated with rotate=2 or 
3; the array index corresponds to body number. 

rotation_origin_x( : ) = 0.0 

This is the ^-coordinate of rotation center; the array index corresponds 
to body number. 

rotation_origin_y ( : ) = 0.0 

This is the //-coordinate of rotation center; the array index corresponds 
to body number. 

rotation_origin_z( : ) = 0.0 

This is the ^-coordinate of rotation center; the array index corresponds 
to body number. 

rotation_vector_x( : ) = 0.0 

This is the ^-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 

rotation_vector_y ( : ) = 1.0 

This is the //-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 

rotation_vector_z( : ) = 0.0 

This is the ^-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 
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rotation_start ( : ) = 0.0 

This is the nondimensional time at which the rotational motion begins 
the array index corresponds to body number. 

rotation_duration( : ) = 1.0e99 

This is the nondimensional time over which the rotational motion is 
active; the array index corresponds to body number. After this time the 
rotational motion is zeroed out. 

translated ) = 0 

This is the type of translational motion; the array index corresponds to 
body number: 

‘ 0 J for no translation. 

1 1 ’ for a constant translation rate, translation_rate. 

‘ 2 J is sinusoidal translation where displacement = translation.amplitude 

sin(27T translation_freq t + translation_phase 7 t/ 180) + translationvtphase 7t/ 180 

and t is nondimensional. 

translation_rate( : ) = 0.0 

This is the nondimensional translation rate associated with translate= 

1; the array index corresponds to body number. 

translation^ req( : ) = 0.0 

This is the nondimensional translation reduced frequency associated with 
translate=2; the array index corresponds to body number. 

translation.phase ( : ) = 0.0 

This is the translation phase shift (in degrees) associated with translate= 

2; the array index corresponds to body number. 

translation.tphase ( : ) = 0.0 

This is the translation offset (in grid units) associated with translate=2; 
the array index corresponds to body number. 

translation_amplitude ( : ) = 0.0 

This is the translation amplitude (in grid units) associated with translate= 

2; the array index corresponds to body number. 

translation_vector_x( : ) = 0.0 

This is the x-component of a unit vector along the translation axis; the 
array index corresponds to body number. 
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translation_vector_y ( : ) = 0.0 

This is the ^/-component of a unit vector along the translation axis; the 
array index corresponds to body number. 

translation_vector_z( : ) = 1.0 

This is the ^-component of a unit vector along the translation axis; the 
array index corresponds to body number. 

translation_start ( : ) = 0.0 

This is the nondimensional start time of the translational motion; the 
array index corresponds to body number. 

translation_duration( : ) = 1.0e99 

This is the nondimensional duration of the translational motion; the 
array index corresponds to body number. 


257 



B.5.3 ^observer motion 

This namelist specifies motion of an observer as a function of time for boundary 
animation purposes (see the &boundary_output_variables namelist for more 
details); the animation is output from the point of view of the observer. 


&observer_motion 

ob_parent_name = ' ' 

ob_rotate = 0 

ob_rotation_rate = 0.0 

ob_rotation_f req = 0.0 

ob_rotation_phase = 0.0 

ob_rotation_tphase = 0.0 

ob_rotation_amplitude = 0.0 
ob_rotation_origin_x = 0.0 
ob_rotation_origin_y = 0.0 
ob_rotation_origin_z = 0.0 
ob_rotation_vector_x = 0.0 
ob_rotation_vector_y = 1.0 
ob_rotation_vector_z = 0.0 
ob_translate = 0 

ob_translation_rate = 0.0 

ob_translation_f req = 0.0 

ob_translation_phase = 0.0 
ob_translation_tphase = 0.0 
ob_translation_amplitude = 0.0 
ob_translation_vector_x = 0.0 
ob_translation_vector_y = 0.0 
ob_translation_vector_z = 1.0 

/ 

ob_parent_name = J ’ 


This is the observer parent reference frame. The default indicates the 
inertial reference frame - the same as when observer motion is not ex- 
plicitly specified. 

ob_rotate = 0 

This is the type of rotational motion: 

‘ 0 J for no rotation. 

‘ 1 ’ for a constant rotation rate, ob_rotation_rate. 

‘ 2 J is sinusoidal rotation where 6 = ob_rotation_amplitude sin(27r ob_rotation_f req t + 
ob_rotation_phase 7r/ 180) and t is nondimensional. 

ob_rotation_rate = 0.0 

This is the nondimensional rotation rate associated with rotate=l. 
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ob_rotation_f req = 0.0 

This is the nondimensional rotation reduced frequency associated with 
rotate=2. 

ob_rotation_phase = 0.0 

This is the rotation phase shift (in degrees) associated with rotate=2. 
ob_rotation_tphase = 0.0 

This is the rotation phase shift (in degrees) applied to transform matrix. 

ob_rotation_amplitude = 0.0 

This is the rotation amplitude (in degrees) associated with rotate=2. 

ob_rotation_origin_x = 0.0 

This is the ^-coordinate of rotation center. 

ob_rotation_origin_y = 0.0 

This is the //-coordinate of rotation center. 

ob_rotation_origin_z = 0.0 

This is the z-coordinate of rotation center. 

ob_rotation_vector_x = 0.0 

This is the ^-component of a unit vector along the rotation axis. 
ob_rotation_vector_y = 1.0 

This is the //-component of a unit vector along the rotation axis. 

ob_rotation_vector_z = 0.0 

This is the z-component of a unit vector along the rotation axis. 

obxtranslate = 0 

This is the type of translational motion: 

‘ 0 J for no translation 

‘ 1 ’ for constant translation rate, ob_translate_rate. 

‘ 2 J is sinusoidal translation where displacement = ob_translation_amplitude 
sin(27r ob_translation_freq t + ob_translation_phase pi/180) and t 
is nondimensional. 

ob_translation_rate = 0.0 

This is the nondimensional translation rate associated with translate= 

1. 
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ob_translation_freq = 0.0 


This is the nondimensional translation reduced frequency associated with 
translate=2. 

ob_translation_phase = 0.0 

This is the translation phase shift (in degrees) associated with translate= 
2 . 

ob_translation_tphase = 0.0 

This is the translation phase shift (in degrees) applied to transform ma- 
trix. 

ob_translation_amplitude = 0.0 

This is the translation amplitude (in grid units) associated with translate 
2 . 

ob_translation_vector_x = 0.0 

This is the x-component of a unit vector along the translation axis. 
ob_translation_vector_y = 0.0 

This is the ^/-component of a unit vector along the translation axis. 

ob_translation_vector_z = 1.0 

This is the z-component of a unit vector along the translation axis. 
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B.5.4 Emotion from file 

This namelist specifies rigid body (and grid) motion via a file containing a 4x4 
transform matrix as a function of time. It allows user-defined motion that is 
more general than the motions available in the &f orcedunotion namelist. 


&motion_f rom_f ile 

n_time_slices_f ile ( : ) 
repeat_time_f ile ( : ) 
motion_f ile ( : ) 
motion_f ile_type( : ) 

/ 


= 0 

= 1.0e+99 

_ I I 

= ' transf orm_matrix ' 


n_time_slices_f ile( : ) = 0 

This is the number of transforms (at selected points in time) defining 
the motion of the body; the array index corresponds to body number. 
All the transforms for a particular body are contained in a single file. 


repeat_time_f ile( : ) = 1.0e+99 

This is the nondimensional time when the motion will repeat; the array 
index corresponds to body number. 


motion_f ile( : ) = ; ’ 

This is the name of the ASCII file that contains the transform matrices 
used to set the grid position and orientation of the body for each of the 
specified instants in time; the array index corresponds to body number. 
The following pseudo code illustrates how such a motion file might be 
created: 

loop over time steps 
writeQ simulationrtime 
write () xcg, ycg, zcg 
do i=l,4 

write () transf orm_matrix(i , j ) , j=l,4) 
end do 

end time step loop 

where simulation.time is the nondimensional time, and where xcg, ycg, zcg 
are the coordinates of the center of gravity of the body in grid units. 


motion_f ile_type( : ) = ’ transf orIn_matrix , 

This is the type of transform matrix specified; the array index corre- 
sponds to body number: 

‘ transf orm_matrix ; specifies the transform from inertial coordinates 
to body (moving) coordinates as a matrix. 
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‘ inversevtransf orm’ specifies the transform from body (moving) co- 
ordinates to inertial coordinates as a matrix. 
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B.5.5 ^surface motion from file 

This namelist allows the motion of surface grids to be defined in files. Since 
only the surface is specified, meshjiiovement = ’deform’ must be used to 
deform the volume mesh to conform to the specified surface. These files must 
be named [project_rootnamel_bodyI\LtimestepM.dat, where N is the body 
number and M is the time slice index (1 to n_time_slices). The files are ASCII 
Tecplot files with a zone title line that contains “TIME simulationvtime” , 
where simulationvtime is nondimensional time. The variables in the file are 
the values of x, y, z, as well as id, where id is the global grid number of the 
surface point. 

&surf ace_motion_f rom_f ile 
n_time_slices ( : ) = 0 
repeat_time ( : ) = 1.0e+99 

/ 

n_time_slices ( : ) = 0 

This is the number of equally spaced instants in time (and files describing 
the shape at those times) defining the motion of the body; the array index 
corresponds to body number. Each file contains the surface shape at a 
point in time. 

repeatvtime ( : ) = 1.0e+99 

This is the nondimensional time when the motion will repeat; the array 
index corresponds to body number. 


263 



B.5.6 &sixdof motion 


This namelist provides details of 6-DOF motion simulations. It requires link- 
ing to the 6-DOF library, see section A. 7.5. NOTE: most data in this namelist 
is input as dimensional data. For 6-DOF motion, the variables ref .velocity, 
ref.density and ref.length in the namelist febody .definitions must also 
be set, in units consistent with those used in fesixdof .motion. Note (impor- 
tant): data are assumed to be in FUN3D body coordinates, which are the 
FUN3D coordinates at t=0. Note that the assumption of FUN3D coordinates 
applies to the moments of inertia. 


fesixdof .motion 
mass ( : ) 
cg_x( : ) 
cg_y(:) 
cg_z( : ) 
i_xx( : ) 

i_yy(:) 

i_zz( : ) 
i_xy ( : ) 
i_xz( : ) 
i_yz( : ) 

body_lin_vel ( : , : ) 
body_ang_vel ( : , : ) 
euler_ang( : , : ) 
gravity.dir (1 : 3) 
gravity.mag 
n.extf orce ( : ) 
n.extmoment ( : ) 
file.ext force ( : , : ) 
f ile.extmoment ( : , : ) 
ignore_x_aerof orce ( : ) 
ignore_y_aerof orce ( : ) 
ignore_z_aerof orce ( : ) 
ignore_x_aeromoment ( : ) 
ignore_y_aeromoment ( : ) 
ignore_z_aeromoment ( : ) 
print _sixdof .summary 
use. spec if ied_aero.dat a 
use.restart.mass.properties 


1.0 

0.0 

0.0 

0.0 

1.0 

1.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0 . 0 , 0 . 0 , - 1.0 

32.2 

0 

0 
I I 

I I 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 


mass(:) = 1.0 

This is the mass of the body; the array index corresponds to the body 
number. 
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cg_x ( : ) = 0.0 

This is the ^-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

cg_y(:) = 0.0 

This is the ^/-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

cg_z ( : ) = 0.0 

This is the ^-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

i _xx ( : ) = 1.0 

This is the moment of inertia about the x axis as the body rotates about 
the x axis; the array index corresponds to the body number. 

i-yy(:) = 1-0 

This is the moment of inertia about the y axis as the body rotates about 
the y axis; the array index corresponds to the body number. 

i_zz(:) = 1.0 

This is the moment of inertia about the z axis as the body rotates about 
the z axis; the array index corresponds to the body number. 

i_xy ( : ) = 0.0 

This is the moment of inertia about the x axis as the body rotates about 
the y axis; the array index corresponds to the body number. 

i_xz(:) = 0.0 

This is the moment of inertia about the x axis as the body rotates about 
the z axis; the array index corresponds to the body number. 

i_yz(:) = 0.0 

This is the moment of inertia about the y axis as the body rotates about 
the z axis; the array index corresponds to the body number. 

body_lin_vel ( : , : ) = 0.0 

These are the components of linear velocity; The first array index (rang- 
ing from 1 to 3) corresponds to the x, y, and z components; The second 
array index corresponds to the body number. 

body_ang_vel ( : , : ) = 0.0 

These are the components of angular velocity (degrees/sec); The first 
array index (ranging from 1 to 3) corresponds to the x , y, and z compo- 
nents; The second array index corresponds to the body number. 
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euler_ang( : , : ) = 0.0 

These are the Euler angles (degrees); The first array (ranging from 1 to 
3) corresponds to the rotation angle components; the second array index 
corresponds to the body number. 

gravity_dir (1 : 3) = 0.0, 0.0, -1.0 

This is a unit length gravity vector. 

gravity_mag = 32.2 

This is the magnitude of the gravity vector (default units: ft/ sec 2 ). 
n_extf orce ( : ) = 0 

This is the number of imposed external forces, excluding gravity. The 
array index corresponds to the body number. 

n_extmoment ( : ) =0 

This is the number of imposed external moments; the array index corre- 
sponds to the body number. 

f ile_extforce( : , : ) = ’’ 

This file specifies the external forces; the first array (ranging from 1 
to n_extforce) corresponds to the external force number. The second 
array index corresponds to the body number. 

f ile_extmoment ( : , : ) = ’’ 

This file specifies the external moments; the first array (ranging from 1 
to n_extforce) corresponds to the external force number. The second 
array index corresponds to the body number. 

ignore_x_aeroforce( : ) = .false. 

Flag to ignore the influence of the ^-component of the aerodynamic force 
on the 6DOF motion of the body; the array index corresponds to the 
body number. 

ignore_y_aeroforce( : ) = .false. 

Flag to ignore the influence of the ^/-component of the aerodynamic force 
on the 6DOF motion of the body; the array index corresponds to the 
body number. 

ignore_z_aeroforce( : ) = .false. 

Flag to ignore the influence of the z-component of the aerodynamic force 
on the 6DOF motion of the body; the array index corresponds to the 
body number. 
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ignore_x_aeromoment ( : ) = .false. 

Flag to ignore the influence of the ^-component of the aerodynamic 
moment on the 6DOF motion of the body; the array index corresponds 
to the body number. 

ignore_y_aeromoment ( : ) = .false. 

Flag to ignore the influence of the ^/-component of the aerodynamic mo- 
ment on the 6DOF motion of the body; the array index corresponds to 
the body number. 

ignore_z_aeromoment ( : ) = .false. 

Flag to ignore the influence of the ^-component of the aerodynamic mo- 
ment on the 6DOF motion of the body; the array index corresponds to 
the body number. 

print_sixdof .summary = .false. 

Print out a summary of the 6DOF data for each body at each time step, 
from within the 6DOF solver itself; useful for verifying that the 6DOF 
library is getting the correct data from FUN3D 

use.specif ied_aero_data = .false. 

Use aero forces and moments read from file(s) instead of the computed 
values (used for validating 6DOF library implementation). When this 
option is used, files must be specified for ALL bodies moving under 
6DOF. For body N, the file name must be named specified_aero_data_bodyN.dat 

use_restart _mass_properties = .false. 

Use mass and moments of inertia from the FUN3D restart file instead of 
those in this namelist; only needed FUN3D has modified the mass and 
inertia during the simulation. 
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B.5.7 fcaeroelastic modal data 

This namelist specifies modal data for static and dynamic aeroelastic analysis 
via time integration of the structural dynamics equations (see for example [57]). 

&aeroelastic_modal_data 
plot_modes = .false, 

nmode ( : ) =0 

grefl(:) = 1.0 

uinf ( : ) =0.0 

qinf ( : ) =0.0 

gdispO ( : , :) =0.0 

gvelO ( : , : ) =0.0 

gf orce0( : , : ) =0.0 

gmass ( : , : ) =0.0 

f req( : , : ) =0.0 

damp ( : , : ) =0.0 

moddf 1 ( : , : ) =0 

moddf l_amp( ) =0.0 

moddf l_freq( ) =0.0 
moddf l_t0(: , :) =0.0 

moddf l_add( ) = 0 

mode_f ile_f ormat = 'ascii' 

/ 

plot_modes = .false. 

This generates tecplot files of each mode shape added to the body surface. 
These can be inspected these to insure the validity of input modal surface 
data. 

nmode ( : ) =0 

This is the number of aeroelastic modes used to represent the structural 
deformation; the array index indicates the body number. 

grefl(:) = 1.0 

This is the scaling factor between CFD grid units and the structural 
dynamics equation units; the array index indicates the body number. 

uinf ( : ) = 0.0 

This is the freestream velocity, in structural dynamics equation units; 
the array index indicates the body number. 

qinf ( : ) = 0.0 

This is the freestream dynamic pressure, in structural dynamics equation 
units; the array index indicates the body number. 
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gdispO( : , : ) =0.0 

This is the generalized displacement of a specified mode at the starting 
time step. It is used to perturb a mode to excite a dynamic response. 
The first array index indicates the mode number and the second array 
index indicates the body number. 

gvelO ( : , : ) = 0.0 

This is the generalized velocity of a specified mode at the starting time 
step. It is used to perturb a mode to excite a dynamic response. The 
first array index indicates the mode number and the second array index 
indicates the body number. 

gf orceO ( : , : ) = 0.0 

This is the generalized force of a specified mode at the starting time 
step. It is used to perturb a mode to excite a dynamic response. The 
first array index indicates the mode number and the second array index 
indicates the body number. 

gmass ( : , : ) = 0.0 

This is the generalized mass of a specified mode. The first array index 
indicates the mode number and the second array index indicates the 
body number. 

freq( : , : ) = 0.0 

This is the frequency of specified mode, in rad/sec. The first array index 
indicates the mode number and the second array index indicates the 
body number. 

damp( : , : ) = 0.0 

This is the damping ratio of specified mode. The first array index indi- 
cates the mode number and the second array index indicates the body 
number. 

moddf 1 ( : , : ) =0 

This is the type of time-varying mode perturbation. The first array 
index indicates the mode number and the second array index indicates 
the body number. 

‘ - 1 ’ is the modal displacement and velocity held fixed at the initial 
values specified by gdispO and gvelO, respectively. 

‘ 0 J is no modal perturbation. 

‘ 1 J is a harmonic modal oscillation. 

‘ 2 ’ is a Gaussian pulse modal deflection. 
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‘ 3’ is a step pulse modal deflection. 

‘5’ specifies simultaneous inputs for reduced order model, 
moddf l_amp( : , : ) = 0.0 

This is the amplitude of mode perturbation. The first array index indi- 
cates the mode number and the second array index indicates the body 
number. 

moddf l_freq( ) = 0.0 

This is the frequency of mode perturbation. If moddf 1=2, it is the Gaus- 
sian pulse half-life. The first array index indicates the mode number and 
the second array index indicates the body number. 

moddf l_t0( ) = 0.0 

If moddf 1=1, this is the dimensional time at which the sinusoidal pertur- 
bation starts. If moddf 1=2, this is the dimensional time of the center of 
the Gaussian pulse. If moddf 1=3, this is the start time of a step pulse. 
The first array index indicates the mode number and the second array 
index indicates the body number. 

moddf l_add( ) = 0 

This determines how the modal perturbation is applied. The first array 
index indicates the mode number and the second array index indicates 
the body number. 

‘ 0 ’ replaces the perturbation with the static aeroelastic solution. 

‘ 1 ’ adds the perturbation to an existing static aeroelastic solution (if 
one exists). 

mode_f ile_f ormat = ’ ascii ’ 

This indicates the type and format of the mode-shape files that are read 
by the code. mode_file_f ormat = ’ ascii’ indicates the files are ASCII 
Tecplot files, with a file extension .dat; mode_file_f ormat = ’ stream’ 
indicates binary (stream) DDF files, with a file extension .ddfb. 


270 



B.5.8 ^composite overset mesh 


This namelist provides the input for SUGGAR++ (see the documentation 
supplied with SUGGAR++ for details). 

&composite_overset_mesh 
input_xml_f ile = ' ' 

/ 


input _xml_f ile = J ’ 

This is the hie containing the XML commands for SUGGAR++. Specify 
the same Input. xml hie that was used to generate the initial composite 
grid with the “stand-alone” SUGGAR++ code. 
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B.5.9 &body motion trim 

This namelist provides the input for trimming a moving body to match se- 
lected trim targets. Trim is achieved by moving one or more bodies via rota- 
tion, translation, or modal amplitude. This option often relies on parent-child 
composite bodies. For example, a wing composite body (the parent) may be 
comprised of a main element (a child) and a flap element (another child). If 
the wing composite body is to be trimmed to match both a lift target and a 
pitching moment target, the lift target can be achieved by adjusting the rota- 
tion angle of the wing composite body, and the moment target can be achieved 
by adjusting the rotation angle of the flap element. An imposed restriction is 
that each trim target is achieved by moving a single body; that single body 
could however be a composite parent-child body 

&body_motion_trim 
trim_ref _f rame 
n_trim_targets( : ) 
trim_variable ( : , : ) 
trim_value ( : , : ) 
body_used_f or_trim( : , : ) 
motion_used_f or_trim( : , :) 
mode_used_f or_trim( : , 
per_step_limit ( : , : ) 
update_f requency ( : , : ) 
tr im_ j acobian ( : , : , : ) 

/ 

trim_ref .frame = ’body’ 

This sets the reference frame in which trim targets are to be satisfied. 
Note that wind-aligned trim targets (Cl and Cd) are unaffected by the 
choice of trim_ref .frame. 

n_trim_targets ( : ) = 0 

This sets the number of trim targets for the body; the array index cor- 
responds to body number of the body to be trimmed. 

‘ 0 :max_trim_targets ’ up to three simultaneous trim targets per body; 
trim_variable( : , : ) = ’none’ 

This specifies the force/moment variables to trim to; the array index 
1 corresponds to the trim target from 1 to n.trim.targets set for the 
body; the array index 2 corresponds to the body number of the body to 
be trimmed. 

‘cl’ trims to a specified lift coefficient 
‘ cd ’ trims to a specified drag coefficient 


= 'body' 
= 0 

= ' none ' 
= 0.0 
= 0 

= ' none ' 
= 0 
= 0.0 
= 1 
= 0.0 
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‘ cw’ trims to a specified weight coefficient; weight is assumed to act in 
the (negative) z-direction. Trim is computed as if a thrust is applied 
along the body x-axis to counterbalance drag; if the body x-axis is not 
aligned with the inertial x-axis, this thrust will also have a contribution 
in the inertial z-direction. 

‘ cx ’ trims to a specified force coefficient in the x-direction 

‘ cy ’ trims to a specified force coefficient in the y-direction 

‘ cz ’ trims to a specified force coefficient in the z-direction 

‘ cmx ’ trims to a specified moment coefficient about the x-axis 

‘ cmy ’ trims to a specified moment coefficient about the y-axis 

‘ cmz ’ trims to a specified moment coefficient about the z-axis 

trim_value ( : , : ) = 0.0 

This specifies the desired numerical values of the trim variables at the 
time condition; the array index 1 corresponds to the trim target from 1 
to n_trim_targets set for the body; the array index 2 corresponds to 
the body number of the body to be trimmed. 

body_used_f or_trim( : , : ) = 0 

This specifies the body number of the body that is moved to achieve the 
trim target; the array index 1 corresponds to the trim target from 1 to 
nvtrimvtargets set for the body; the array index 2 corresponds to the 
body number of the body to be trimmed. 

motion_used_f or_trim( : , : ) = ’none’ 

This specifies the type of body motion used to achieve the trim target; the 
array index 1 corresponds to the trim target from 1 to nvtrimvtargets 
set for the body; the array index 2 corresponds to the body number of 
the body to be trimmed. 

‘ rotate J trims by rotating the body_used_f or.trim 

‘ translate 5 trims by translating the body_used_f or_trim 

'mode’ trims by adjusting modal amplitude of the body_used_f or.trim 

mode_used_f or_trim( : , : ) = 0 

This specifies the aeroelastic mode number used to achieve the trim 
target; only used for modal aeroelastic simulations, and only active when 
motion_used_for_triIn= , mode , ; the array index 1 corresponds to the 
trim target from 1 to n_trim_targets set for the body; the array index 
2 corresponds to the body number of the body to be trimmed. 
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per_step_limit ( : , : ) = 0.0 

This specifies the maximum amount that the motion_usecLf orvtrim can 
change during each attempt to achieve trim; if the motion is rotation, 
the units are degrees; if translation, the units are grid units; if modal 
amplitude, the units are (I have no idea); the array index 1 corresponds 
to the trim target from 1 to n_trim_targets set for the body; the array 
index 2 corresponds to the body number of the body to be trimmed. 

update_f requencyC : , : ) = 1 

This specifies the frequency with which the trim variable is updated 
trim_jacobian( : , : , : ) = 0.0 

This specifies the sensitivities of the specified trira_variable(s) to a 
change in the specified motion_used_f or_trim(s). Thus it is an n_trim_targets 
x n_trim_targets array for each body with trira_control = ’ bodyunotion’ . 
The array index 1 corresponds to the trim variable, array index 2 cor- 
responds to the control motion, the array index 3 corresponds to the 
body number of the body to be trimmed. The sign of the entries is 
important. For example, if the trim variable is lift, and the motion is 
rotation, then if an increase in the rotation angle produces an increase 
in lift, then the sign of that entry in trim.jacobian should be positive. 
Conversely, if an increase in rotation angle produces a decrease in lift, 
then the sign of that entry in trim_jacobian should be negative. If the 
motion_used_f or_trim is rotation, the sensitivity is assumed to be input 
per degree. 
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B.6 rotor, input 


Fun3D is capable of modeling a rotating blade system using different levels of 
approximation. In order of increasing complexity /fidelity /cost, rotor systems 
may be analyzed using either a time-averaged actuator disk, or via first prin- 
ciples modeling of the moving, articulated, rotor blades using overset, moving 
grids. The actuator method utilizes momentum/energy source terms to rep- 
resent the influence of the rotating blade system. Use of the source terms 
simplifies grid generation, since the actuator surfaces do not need to be built 
into the computational grid. However, the computational grid should have 
some refinement in the vicinity of the actuator surfaces to obtain accurate 
results. The steady-state actuator disk capability was originally implemented 
by Dave O’Brien, at the time a PhD candidate at Georgia Tech. [58] O’Brien 
also initiated the overset capability in Fun3D, which was later extended and 
coupled to a rotorcraft comprehensive code by Biedron et al. [59] 

The rotor. input hie is used primarily for specifying input quantities related 
to an actuator surface model for rotor /propeller combinations. When using 
overset, moving grids and/or coupling Fun3D to a rotorcraft comprehensive 
code for a more detailed simulation, a limited number of the input fields in 
the rotor. input hie are also required. The helds required for coupled ro- 
torcraft simulations include (required for coupled simulation) in the variable 
description. The command line option — rotor is required for both types of 
analysis. 

Fun3D can also use the actuator disk library developed by Dave O’Brien 
for the Department of Defense HI-ARMS/CREATE/HELIOS project, Soft- 
ware Module for Engineering Methods of Rotor Dynamics (SMEMRD). The 
Fun3D team is unable to provide technical support for SMEMRD; please 
contact Dave O’Brien directly for assistance (David.ObrienJr@us.army.mil). 
SMEMRD adds the ability to trim to thrust values and use airfoil lookup 
tables. The --hiarms_rotor command line option activates the SMEMRD 
model. 

The two parameters used to set the flight condition and force/moment coef- 
ficient normalization in compressible rotorcraft simulations are mach_number in 
fun3d.nral and Vinf_Ratio in rotor. input. To nondimensionalize the forces 
with the rotor tip velocity, set mach_number to the tip mach number and 
Vinf_Ratio to the ratio of freestream velocity to rotor tip velocity (the he- 
licopter advance ratio). When mach_number is the tip mach number then 
reynolds_number should be set to the corresponding tip Reynolds number. 
To nondimensionalize the forces with the freestream velocity, set mach_number 
to the freestream mach number and Vinf _Ratio to one. The Vinf -Ratio will 
still affect the force nondimensionalization as described above, for incompress- 
ible solutions. 

A sample rotor, input file is shown below for a conventional main rotor 
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and tail rotor helicopter. 


# Rotors 

Vinf _Ratio 

Write Soln 

Force_ref 

Moment_ref 


2 

0.1 

50 

1.0 

1.0 







Rotor Type 

Load Type 

# Radial 

# Normal 

Tip Weight 


1 

0 

50 

720 

0.0 


X0_rotor 

Y0_rotor 

Z0_rotor 

phil 

phi2 

phi3 

0.00 

0.00 

0.00 

0.00 

-5.00 

0.00 

Vt_Ratio 

Thrust Cof f 

PowerCof f 

psiO 

PitchHinge 

DirRot 

1.00 

0.005 

-1.00 

0.00 

0.0 

0 

# Blades 

TipRadius 

RootRadius 

BladeChord 

FlapHinge 

LagHinge 

4 

1.00 

0.00 

0.05 

0.00 

0.00 

LiftSlope 

alpha, L=0 

cdO 

cdl 

cd2 


6.28 

0.00 

0.002 

0.00 

0.00 


CL_max 

CL_min 

CD_max 

CD_min 

Swirl 


1.50 

-1.50 

1.50 

-1.50 

0 


ThetaO 

ThetaTwist 

Thetals 

Thetalc 

Pitch-Flap 


5.00 

-2.00 

0.00 

0.00 

0.00 


# FlapHar 

BetaO 

Betals 

Betalc 



0 

0.00 

0.00 

0.00 



Beta2s 

Beta2c 

Beta3s 

Beta3c 



0.00 

0.00 

0.00 

0.00 



# LagHar 

DeltaO 

Deltals 

Deltaic 



0 

0.00 

0.00 

0.00 



Delta2s 

Delta2c 

Delta3s 

Delta3c 



0.00 

0.00 

0.00 

0.00 








Rotor Type 

Load Type 

# Radial 

# Normal 

Tip Weight 


1 

0 

100 

720 

0.0 


X0_rotor 

Y0_rotor 

Z0_rotor 

phil 

phi2 

phi3 

1.00 

0.00 

0.00 

90.00 

0.00 

0.00 

Vt_Ratio 

Thrust Cof f 

PowerCof f 

psiO 

PitchHinge 

DirRot 

1.25 

0.001 

-1.00 

0.00 

0.0 

0 

# Blades 

TipRadius 

RootRadius 

BladeChord 

FlapHinge 

LagHinge 

3 

0.20 

0.00 

0.01 

0.00 

0.00 

LiftSlope 

alpha , L=0 

cdO 

cdl 

cd2 


6.28 

0.00 

0.002 

0.00 

0.00 


CL_max 

CL_min 

CD_max 

CD_min 

Swirl 


1.50 

-1.50 

1.50 

-1.50 

1 


ThetaO 

ThetaTwist 

Thetals 

Thetalc 

Pitch-Flap 


8.00 

0.00 

0.00 

0.00 

0.00 


# FlapHar 

BetaO 

Betals 

Betalc 



0 

0.00 

0.00 

0.00 



Beta2s 

Beta2c 

Beta3s 

Beta3c 



0.00 

0.00 

0.00 

0.00 



# LagHar 

DeltaO 

Deltals 

Deltaic 



0 

0.00 

0.00 

0.00 



Delta2s 

Delta2c 

Delta3s 

Delta3c 



0.00 

0.00 

0.00 

0.00 




The header line is where the user specifies the number of rotors, the rotor 
advance ratio, and how often to output the plot3d loading hie. The remainder 
of the hie is in a block structure, where each block represents the inputs for 
one rotor. The hrst line of each block is a text line that can be edited to keep 
the rotors organized for the user. The input values do not have to be in a hxed 
format (spaces and number of decimal points do not matter), but the input 
values do have to be in the correct order as noted by the header lines for the 
individual input parameters. 
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B.6.1 Header 

# Rotors (required for coupled simulation) 

This is the number of actuator surfaces to create. The number of rotor 
input blocks in this file must match the number of rotors specified. 

Vinf .Ratio (required for coupled simulation) 

This is the ratio of the freestream velocity to the the velocity used for 
force normalization. This velocity used for force normalization is typi- 
cally the tip velocity for rotorcraft applications; in that case, Vinf .Ratio 
is the advance ratio and mach_number is the freestream velocity. 

Write Soln 

This is the frequency (in iterations) of Plot3D rotor loading data output, 
which is pairs of source_grid_00000.p3d and source_data_00000.p3d 
hies. To write once, set Write Soln to steps. 

Force_ref 

This is the conversion factor to obtain forces in alternate units, 

1.0 will output the standard Fun 3D nondimensionalization 

(Llefofef) / (tt R fotorVup) output standard rotorcraft nondimension- 

alization 

Pref a r e f^ref will output dimensional units 
Moment_ref 

This is the conversion factor to obtain moments in alternate units. 

1.0 will output the standard Fun 3D nondimensionalization 

(L). e faf e f)/(7tR) otor V£ p ) will output standard rotorcraft nondimension- 
alization 

PrefC'refLref will output dimensional units 

B.6.2 Actuator Surface Model 
Rotor Type 

Type of rotor model to apply, 

1 models the rotor as an actuator disk. 

2 models the rotor as actuator blades. 

Load Type 

Type of loading to apply to the rotor model. 
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1 is a pressure jump based on ThrustCoeff that is constant over the 

disk. 

2 is a pressure jump based on ThrustCoeff that increases linearly with 

radius. 

3 is blade element based loading based defined by the blade element 

parameters defined in section B.6.6 and section B.6.7. 

4 is user specified source geometry and strength. Not recommended un- 

less you have experience in actuator disk modeling. See the subrou- 
tine read_user_source2 in LibF90/rotors.f90 for input format. 

5 is user specified thrust and torque radial distributions in the file 

propeller_propertiesN.dat, where N is the rotor index. The first 
line of the file is the number of radial stations. The following lines 
have three numbers per station, with r/R, f^/R) ’ d(r/R) • 

# Radial 

This is the number of sources to distribute along the blade radius. This 
should be set to approximately match the resolution of the volume grid, 
otherwise a suggested value is 100. 

# Normal 

This is the number of sources to distribute along the circumferential 
direction. This should be set to approximately match the resolution 
of the volume grid. For Rotor Type=l, 720 is suggested for a source 
every 0.5 degrees. For Rotor Type=2, 20 points in the chord direction is 
suggested. 

Tip Weight 

This is the hyperbolic weighting factor for distributing sources along the 
blade radius. A suggested value is 0.0, which yields uniform distribu- 
tion. A value larger than 2.0 is not advised, because this large a value 
concentrates too many sources at the blade tip. 

B.6.3 Rotor Reference System 

XCLrotor (required for coupled simulation) 

This is the x coordinate of the hub center of rotation, in grid units. 
YCLrotor (required for coupled simulation) 

This is the y coordinate of the hub center of rotation, in grid units. 
ZCLrotor (required for coupled simulation) 

This is the z coordinate of the hub center of rotation, in grid units. 
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phil 


This is the first Euler angle describing a rotation about the x axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be 0. 

phi2 

This is the second Euler angle describing a rotation about the 02 axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be -90. 

phi3 

This is the third Euler angle describing a rotation about the 63 axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be 0. 

The Euler angles must be input correctly to obtain the correct orientation 
of the source based actuator disk. The following example illustrates how to 
determine these angles. Figure B5 depicts the rotations phil = 10, phi2 = 
— 15, and phi3 = 15. Initially, the thrust is assumed to be in the 2 direction 
and the disk is located in the x — y plane. The first rotation of phil about 
the x axis takes the x — y — z system to the ay — 02 — 03 system shown in red. 
The second rotation of phi2 about the 02 axis takes the ay — 02 — 03 system 
to the b\ — 62 — ^3 system shown in green. The final rotation of phi3 about 
the 63 axis takes the 61 — &2 — system to the rotor reference system shown in 
blue. The black circle represents the initial disk orientation and the blue circle 
represents the final disk orientation. In general phil and phi2 are sufficient 
to define the thrust orientation. The variable phi3 only changes the location 
of the zero azimuth angle definition for the rotor. 



Figure B5: Rotor disk Euler angles. 
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B.6.4 Rotor Loading 

Vt_Ratio (required for coupled simulation) 

This is the ratio of the tip speed to the velocity used for force normal- 
ization. If the force normalization velocity is freestream, then Vt_Ratio 
= l/(advance ratio). For Load Type = 3, a negative value will reverse 
the rotation direction. 

ThrustCof f 

This is the rotor thrust coefficient defined as, Ct = Thrust / ( ti p re fR 2 {yLD im R ) 2 ), 
when Load Type=l or Load Type=2. The blade element model does not 
trim to specified thrust coefficient. 

PowerCoLf 

This is the rotor power coefficient [Not implemented]. 


B.6.5 Blade Parameters 

psiO (required for coupled simulation) 

This is the initial azimuthal position of blade one, in degrees; the azimuth 
position is defined as zero when the blade is oriented along the x-axis 
with the tip at the most positive x location. 

PitchHinge (required for coupled simulation) 

This is the radial position of the blade pitch hinge normalized by tip 
radius. 

DirRot (required for coupled simulation) 

This is the direction of rotor rotation. Zero is counter-clockwise rota- 
tion and one is clockwise rotation. This option only applies to coupled 
simulation, not actuator models. 

# Blades (required for coupled simulation) 

This is the number of rotor blades. It is only used for Load Type=3 and 
overset rotor simulations. 

TipRadius (required for coupled simulation) 

This is the radius of the blade, in grid units. 

RootRadius (required for coupled simulation) 

This is the radius of the blade root, in grid units. It accounts for the 
cutout region immediately surrounding the hub. 


280 



BladeChord (required for coupled simulation) 

This is the chord length of the blade, in grid units. It can only handle 
rectangular blade planforms and is only valid for Load Type=3. 

FlapHinge (required for coupled simulation) 

This is the radial position of the blade flap hinge normalized by tip 
radius. 

LagHinge (required for coupled simulation) 

This is the radial position of the blade lag hinge normalized by tip radius. 

B.6.6 Blade Element Parameters for Load Type=3 

These inputs are used to set the blade element lift and drag curves according 
to: 

Cl = LiftSlope(a — a.L=o) (Bl) 

and 

Cd = cdO + cdl a + cd2 a 2 (B2) 


LiftSlope 

This is the lift curve slope per radian, 
alpha, L=0 

This is the zero lift angle of attack, in degrees. 

cdO, cdl, and cd2 

These are the quadratic drag polar coefficients; where cdl is per radian 
and cd2 is per radian squared. 

CL_max and CL_min 

These limiters to control the lift coefficient beyond the linear region. 
CDanax and CD_min 

These limiters to control the drag coefficient. 

Swirl 

0 neglects the sources terms that create rotor swirl. 

1 the swirl inducing source terms. 
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B.6.7 Pitch Control Parameters for Load Type=3 

These inputs are used to specify the pitch/flap controls according to: 

9 = ThetaO + ThetaTwist ( r/R ) + Thetalc cos(^) + Thetals sin ('(/;) (B3) 
ThetaO 

This is the collective pitch defined at r/R— 0, in degrees. 

ThetaTwist 

This is the total amount of linear blade twist from the origin to the blade 
tip. in degrees. 

Thetals 

This is the longitudinal cyclic pitch input, in degrees. 

Thetalc 

This is the lateral cyclic pitch input, in degrees. 

Pitch-Flap 

Pitch-Flap coupling parameter [not implemented]. 

B.6.8 Prescribed Flap Parameters 

These inputs are used to specify the flap harmonics according to: 

f3 = BetaO + Betals sin(^) + Betalc cos(^) 

+Beta2s sin(2'0) + Beta2c cos(2^>) (B4) 

+Beta3s sin(3'0) + Beta3c cos(3t/) 

# FlapHar 

This is the number of flap harmonics to include. The valid input range 
is zero to three. 

BetaO 

This is the coning angle, in degrees. 

Betals and Betalc 

This is the first flap harmonics, in degrees. 

Beta2s and Beta2c 

This is the second flap harmonics, in degrees. 

Beta3s and Beta3c 

This is the third flap harmonics, in degrees. 
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B.6.9 Prescribed Lag Parameters 

These inputs are used to specify the lag harmonics according to: 


5 = DeltaO + Deltals sin(^) + Deltaic cos(^) 

+Delta2s sin(2'0) + Delta2c cos(2^) (B5) 

+Delta3s sin(3V0 + Delta3c cos(3^) 


# LagHar 

This is the number of lag harmonics to include. The valid input range 
is zero to three. 

DeltaO 

This is the coning angle, in degrees. 

Deltals and Deltaic 

This is the first lag harmonics, in degrees. 

Delta2s and Delta2c 

This is the second lag harmonics, in degrees. 

Delta3s and Delta3c 

This is the third lag harmonics, in degrees. 

B.7 tdata 

This file defines the gas model when eqn.type = ’generic’. A keyword is 
required on the first line of tdata. Many of these models require additional 
information as detailed in each keyword section. 

Some keywords require a list the species. For these keywords, additional 
groups of species can be specified for boundary conditions after a blank line. 
If new species are introduced in subsequent instances their mass fractions are 
automatically initialized to zero at any previous inflow boundary. All the 
species entries in this file are available as reactants throughout the entire flow 
field. 

B.7.1 perfect_gas Keyword 

A perfect gas can be modeled with the perf ect_gas keyword. The parameters 
can be explicitly defined in tdata by the namelist &species_properties. The 
namelist in tdata has different variables than the &species_properties in 
species_thermo_data. Here is an example of the namelist with defaults that 
are all given in SI units, 
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perf ect_gas 
fespeci es_properti.es 


gamma 

mol_wt 

sutherl 

suther2 

prand 

/ 


1.4 

28.8 

0. 1458205E-05 
110.333333 
0.72 


Where gamma is the gas specific heat ratio, mol_wt is the gas molecular weight, 
prand is the gas Prandtl number, and sutherl and suther2 are the first and 
second Sutherland’s viscosity coefficients, Si and s 2 , in 


T 3/2 


/i 5l 


T + s 2 


(B6) 


These defaults are used if the &species_properties namelist or any of its 
variables are omitted. 


B.7.2 equilibrium_air_t Keyword 

The equilibrium_air_t keyword engages the Tannehill curve fits for thermo- 
dynamic and transport properties of equilibrium air. [60] This keyword does 
not require additional lines. 

equilibrium_air_t 

B.7.3 equilibrium_air_r Keyword 

The equilibrium_air_r keyword engages the Tannehill curve fits for transport 
properties and a table look-up for equilibrium gases [61], This keyword does 
not require additional lines. 

equilibrium_air_r 
B.7.4 one Keyword 

This one-temperature (1-T) model assumes that all the species are thermally 
in equilibrium state; the translational temperature T and vibrational tempera- 
ture T v are equal. This is a mixture of thermally perfect gases and multi-species 
transport. In this example, only molecular oxygen and nitrogen are present 
on the inflow boundary, but atomic nitrogen and oxygen and nitric oxide may 
be produced elsewhere in the flow held due to chemical reactions. The inflow 
boundary mass fraction of molecular oxygen and nitrogen is given next to their 
symbols. Mass fractions should sum to one. 
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one 

N2 .767 
N 

02 .233 

0 

NO 

B.7.5 two Keyword 

This two-temperature (2-T) model assumes that energy distribution in the 
translational and rotational modes of heavy particles (not electrons) are equili- 
brated at translational temperature T and all other energy modes (vibrational, 
electronic, electron translational) are equilibrated at vibrational temperature 
T v . In this example, the gas is assumed to be a mixture of 11 thermally perfect 
gases. The inflow boundary mass fraction of molecular oxygen and nitrogen is 
given next to their symbols. Mass fractions should sum to one. Other products 
are the results of chemical reactions flow field. 

two 

N2 .767 
N 

02 .233 

0 

NO 

02 + 

0 + 

N0+ 

e- 

B.7.6 FEM Keyword 

This Free-Energy Minimization (FEM) model causes the species continuity 
equations to be replaced with elemental continuity equations and equilibrium 
relations for remaining species. In this example, the gas is assumed to be a 
mixture of 11 thermally perfect gases. The inflow boundary mass fraction of 
molecular oxygen and nitrogen is given next to their symbols. Mass fractions 
should sum to one. Other products are the results of chemical reactions flow 
held. 

FEM 

N2 .767 
N 

02 .233 

0 

NO 

02 + 
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0 + 

N0+ 

e- 


B.8 species_thermo_data 

The species_thermo_data file is the master hie for species thermodynamic 
data. The majority of simulations do not require changes to this hie. Investi- 
gating other sources of thermodynamic data is the only reason to edit this hie. 
If the hie is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_raodules directory. See section A. 3 
for [install-prefix]. 

Each species record consists of the species name, a &species_properties 
namelist, the number of thermodynamic property curve ht ranges, and the 
curve ht coefficients for each range. [62] No blank line is allowed in this 
hie. This &species_properties namelist has different variables than the 
&species_properties in tdata. The elements of the &species_properties 
namelist are: 
mol_wt 

This sets the molecular weight of the particle. It is always required. 

molecule = .false. 

This is denotes the the species a molecule (composed of more than one 
atom); 

ion = .false. 

This is denotes the the species a charged particle. Do not set it for neu- 
trals and electrons. This will initializes electron-neutral energy exchange 
cross section and sum of the charges. 

charge = 0 

This is an integer number to determine number of positive charges in 
particle. It should only be used with ion = .true. 

elec_impct_ion = -l._dp 

This sets the energy for neutrals ion=. false, that is required to liberate 
an electron when the neutral impact a free electron, in units of electron 
volts (eV). 

siga( : ) = - 1 . _dp 

This is an array of three real numbers, which correspond to the curve 
fit coefficients for electron-neutron energy exchange. The cross section 
is defined as 

<r en = a + bT + cT 2 (B7) 
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where a en is the electron-neutron energy exchange collision cross section 
in m 2 . The variables a, b , and c are the curve fit coefficients and T is 
the gas temperature. [63,64] For example, siga=7.5e-20 , 0, 0. 

disoc_ener = 0._dp 

This is the dissociation energy of molecule in electron volts (eV). 

alantel = 0._dp 

This is the Landau- Teller constant to compute vibrational relaxation 
time for molecule. [65,66]. It is required when raolecule=.true.. 

cprtO = 0._dp 

This non-dimensional real number defines translational-rotational heat 
capacity. It is normalized by the gas constant and is equal to 

f + 2 

cprtQ = — (B8) 

where / is the number of degrees of freedom in translation and rota- 
tion. The defaults for atoms and diatomic molecules are 2.5 and 3.5, 
respectively. 

A portion of the species_thermo_data that provides thermodynamic prop- 
erties of carbon is shown below. 


C i 
&species_properties 2 
molecule = .false. 3 
ion = .false. 4 


charge = 0 

elec_impct_ion = 11.264 
siga = 7.5e-20, 5.5e-24, -l.e-28 
mol_wt = 12.01070 
/ 


0 . 64950315E+03 
0.19801337E-07 
0 . 85457631E+05 
-0.12891365E+06 
0 . 17420927E-06 
0 . 84105978E+05 
0 . 44325280E+09 
0.66495953E-06 
0 . 23552734E+07 


-0 . 96490109E+00 
-0.16061440E-10 
0 . 47479243E+01 
0. 17195286E+03 
-0 . 29028 178E- 10 
0 . 41300474E+01 
-0 . 28860184E+06 
-0.22300788E-10 
-0 . 64051232E+03 


0 . 25046755E+01 
0 . 53144834E-14 
200.000 1000 
0 . 26460444E+01 
0. 16421824E-14 
1000.000 6000 
0 . 7737 1083E+02 
0 . 28993887E-15 
6000.000 20000 


-0.12814480E-04 

0.00000000E+00 

000 

-0.33530690E-03 

0.00000000E+00 

000 

-0.97152819E-02 

0.00000000E+00 

000 


5 


7 


9 

10 

11 

12 

13 

14 

15 

16 

17 

18 
19 


The species name is defined in line 1. Between lines 2 and 9 species properties 
are defined. Line 10 shows that there are three thermodynamic property curve 
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fits for temperature ranges of 200 K < T < 1,000 K, 1,000 K < T < 6,000 K, 
and 6,000 K < T < 20,000 K. Each data range consists of 12 real numbers. 
Four real numbers must be given on each line. The first 10 real numbers are the 
thermodynamic curve fit coefficients, and the last two real numbers identify 
the temperature range for the given curve fit coefficients. These coefficients 
are used to calculate the following thermodynamic properties 


c p (T)/R — a{T 2 + CI 2 T 1 + 03 + CI 4 T + < 2 . 5 T 2 + + CZ 7 T 4 (B9) 

h(T)/RT = —a\T 2 + a 2 T (B10) 

rji — 2 rj-^2 J-i3 rj'i 

s(T)/R = — cp— — CL 2 T 1 -\-CL 3 ln T + g^TT (B ll) 

where T is the gas temperature, R is the universal gas constant, c p , h, and s 
are the species specific heat, enthalpy and entropy, respectively, and a* are the 
provided curve fit coefficients in species_thermo_data. 

The following corrections will be applied if the gas temperature is out of 
the given range for the given curve fit coefficients: 



e„(T) = c r (T •) 

(B12) 


h(T) = h{T *) + (T - T*)c p (T*) 

(B13) 


s(T) = s(T) + In A Cp (T* ) 

(B14) 

where 

rji* f Ti ower for T <c Ti ower 

Supper T ]> T upper 

(B15) 

B.9 

kinetic_data 


The kinetic_data hie defines possible chemical reactions and is optional. If 
the hie is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_raodules directory. See section A. 3 
for [install-prefix] . Reactants and products can be any species defined in 
the species_therrao_data described in section B. 8 . A sample entry looks like 


02 + M <=> 20 + M 

2 . 000e+21 -1.50 5.936e+04 

teffl = 2 

expl = 0.7 

t_eff_min = 1000. 

t_eff_max = 50000. 

C = 5.0 
0 = 5.0 
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1 

2 

3 

4 

5 


7 


8 


9 


10 
11 
12 

The first line specifies the reaction while line 2 provides three coefficients of 
an Arrhenius-like equation, 

K, = (B16) 

where c/ is the pre-exponential factor, r) is the power of temperature depen- 
dence on the pre-exponential factor, eo is the Arrhenius activation energy, and 
k is the Boltzmann constant. The arrowheads in line 1 signify the allowed 
directionality of the reaction. The symbol => denotes forward reaction only 
while <=> denotes forward and backward rates are computed. The coefficients 
in line 2 correspond to C/, r/, and eo/k, respectively. For reactions with a 
generic collision partner, M, such as this one, these coefficients correspond to 
Argon; and other collision partners and their efficiencies (multipliers of Cf ) 
are specified on lines following line 5 and 6, which give the valid temperature 
range for the reaction. The effective temperature, T e ff, is defined according 
to a given integer number in line 3. 

teff 1 = l,tef f 2 = 1 

This defines the formula to compute the effective temperature T e ff for 
the forward rate and backward rate, respectively. It is engaged for the 
case of thermal nonequilibrium. Options for teff are: 

1: Teff = Ttr 

O. rp rpexplrpl — expl 

1 eff — 1 tr 1 v 

3: Teff = T v 

where T tr and T v are translational and vibrational temperatures, respec- 
tively. 

expl = 0.7 

This is the exponent used to define the effective temperature when 
teff 1= 2 (forward rate) or teff 2 = 2 (backward rate). 

rf_max = l.e+20 

This is the upper limit on forward reaction rate in cgs units when 
augment _kinetics_limiting = .true. For unlimited rates as function 
of temperature, see the output file kinetic_diagnostics_output. 


N = 5.0 
H = 5.0 
Si = 5.0 
e- = 0 . 
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rf_min = l.e-30 


This is the lower limit on forward reaction rate in cgs units when 
augment_kinetics_limiting= .true. For unlimited rates as function of 
temperature, see the output file kinetic_diagnostics_output. 

rb_max = l.e+30 

This is the upper limit on backward reaction rate in cgs units when 
augment_kinetics_liraiting = .true. For unlimited rates as function 
of temperature, see the output hie kinetic_diagnostics_output. 

rb_min = l.e-30 

This is the lower limit on backward reaction rate in cgs units when 
augment_kinetics_liraiting = .true. For unlimited rates as function 
of temperature, see the output hie kinetic_diagnostics_output. 

t_eff_min = 1000. 

This is the minimum temperature for T e ff. This may circumvent stiff 
source terms when computing reaction rates. 

t_eff_max = 50000. 

The maximum temperature for T e ff. This may circumvent stiff source 
terms when computing reaction rates. 

B.10 species_transp_data 

The species_transp_data hie contains log-linear curve ht coefficients for 
species collision cross sections that are defined based on temperature range 
of 2,000-4,000 K. [64] This temperature range spans boundary- layer temper- 
atures for typical hypersonic entry. The curve ht for the given coefficients is 
poor at temperatures below 1,000 K. Higher order curve ht data is available 
in species_transp_data_0. The hie should not be changed by the user unless 
there is a need to investigate other sources of collision cross-section data. If 
the hie is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_modules directory. See section A. 3 
for [install-prefix] . An example of the entries in the hie is 


Ar Ar i 
-14.6017 -14.6502 -14.5501 -14.6028 ! trrl32+kestin et al 2 
Ar+ Ar+ 3 
-11.48 -12.08 -11.50 -12.10 4 
Ar N2 5 
-14.5995 -14.6475 -14.5480 -14.5981 ! kestin et al e 
Ar CO 7 
-14.5975 -14.6455 -14.5459 -14.5964 ! kestin et al s 
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B.ll species transp data 0 

The file species_transp_data_0 provides collision cross section coefficients 
[67,68] for a higher order curve fit data than those that are in the species_transp_data. 
The data in species_transp_data_0 supersedes the data in species_transp_data 
The file should not be changed by the user unless there is a need to investi- 
gate other sources of collision cross-section data. If the file is not found in 
the local run directory, it is assumed to be located in the [install-prefix] 
/share/physics_modules directory. See section A. 3 for [install-prefix]. 

An example of the entries in the file is 


02 N 


NO N 


NO 0 


111 (c 

-1. 1453028E-03 
-1.0608832E-03 
1 . 4943783E-04 

111 (c 

-1 . 57709 18E-03 
-1.47 19259E-03 
2. 1014557E-04 

111 (c 

-1.0885815E-03 
-1.0066279E-03 
1 . 4145458E-04 


1.2654140E-02 
1. 1782595E-02 
-2.0389247E-03 


1 . 9578381E-02 
1 . 8446968E-02 
-3.0420763E-03 


1. 1883688E-02 
1. 1029264E-02 
-1 . 924927 IE-03 


-2.2435218E-01 
-2. 1246301E-01 
1 . 8536165E-02 


-2.7873624E-01 
-2.6460411E-01 
2 . 5736958E-02 


-2. 1844909E-01 
-2.0671266E-01 
1 . 7785767E-02 


7 . 7201588E+01 
8 . 4561598E+01 
1 . 0476552E+00 


9 . 9547944E+01 
1 . 0911124E+02 
1 . 0359598E+00 


7 . 5512560E+01 
8 . 2644384E+01 
1 . 0482162E+00 


END END 
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B.12 hara_namelist_data 

The hara_namelist_data file controls the radiation models used by the Hara 
radiation module. [69,70] It is optional for coupled radiation simulations. If it is 
not present, then the code automatically chooses the radiative mechanisms as- 
sociated with species present in the flowfield that have number densities greater 
than 1000 particles/cm 2 ) Other options are set to the defaults. For users not 
experienced in shock-layer radiation, the recommended default options should 
be used, this hara_namelist_data A default hara_namelist_data is available 
in the PHYSICS_M0DULES directory of the Fun3D distribution. 


specifying radiation mechanisms for atomic species: The treatment 

of radiation resulting from atomic lines, atomic bound-free, and free-free pho- 
toionization (referred to here as atomic continuum), and negative ion contin- 
uum is available for atomic carbon, hydrogen, oxygen, and nitrogen. These 
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mechanisms are specified through the following binary flags (on=l/off=0). If 
any of these flags are not present in hara_namelist_data, then that flag is set 
to true only if the number density of the associated atomic species is greater 
than 1000 particles/cm 2 somewhere in the flowfield. 

treat, [?] _lines 

A binary flag to enable the treatment of atomic lines for species [?] , 
where [?] can be c, h, n, and o, for atomic carbon, hydrogen, nitrogen 
and oxygen, respectively. 

treat, [?] _cont 

A binary flag to enable the treatment of atomic bound-free and free-free 
continuum for species [?] , where [?] can be c, h, n, and o, for atomic 
carbon, hydrogen, nitrogen and oxygen, respectively. 

treat, [?] _other 

A binary flag to enable the treatment of the negative-ion continuum for 
species [?] , where [?] can be c, h, n, and o, for atomic carbon, hydrogen, 
nitrogen and oxygen, respectively. 


specifying radiation mechanisms for molecular species: The treat- 

ment of radiation resulting from numerous molecular band systems is avail- 
able through the following flags (0 = off, 1 = SRB, 2 = LBL). The smeared 
rotational band (SRB) approach applies a simplified and efficient treatment of 
each molecular band system, which is accurate for optically thin conditions. 
The line-by-line (LBL) approach is a detailed but highly inefficient treatment 
of each molecular band system. The LBL option is not recommended for cou- 
pled radiation-flowfield computations, except for possibly the CO 4+ system, 
which may be optically thick for Mars entry conditions. If any of these flags 
are not present in hara_namelist_data, then that flag is set to the SRB option 
only if the number density of the associated molecular specie is greater than 
1000 particles/cm 2 somewhere in the flowfield. Additional band systems are 
listed in the following paragraph. These additional band systems are gener- 
ally considered negligible relative to those listed in this section. Therefore, for 
computational efficiency, they are not engaged by default. Definitions of each 
band system and the modeling data applied are discussed in Refs. [69,71]. 

treat_band_c2_swan 

A flag activating the C 2 Swan band system. 

treat_band_c2h 

A flag activating the C 2 H band system. 
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treat_band_c 3 

A flag activating the C3 and vacuum ultra-violet (VUV) band systems. 

treat _band_cn_red 

A flag activating the CN red band system. 

treat_band_cn_violet 

A flag activating the CN violet band system. 

treat _band_co 4 p 

A flag activating the CO 4 + band system. 

treat_band_co_bx 

A flag activating the CO B-X band system. 
treat _band_co_cx 

A flag activating the CO C-X band system. 
treat_band_co_ex 

A flag activating the CO E-X band system. 

treat _band_co_ir 

A flag activating the CO X-X band system. 

treat _bandJi2_lyman 

A flag activating the H2 Lyman band system. 

treat _band_h2_werner 

A flag activating the H2 Werner band system. 

treat _band_n2fp 

A flag activating the N 2 1 + band system. 

treat _band_n2sp 

A flag activating the N 2 2+ band system. 

treat _band_n2pfn 

A flag activating the first-negative band system. 

treat_band_n2_bhl 

A flag activating the N 2 Birge-Hopheld I band system. 

treat_band_n2_bh2 

A flag activating the N2 Birge-Hopheld II band system. 
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treat_band_no_beta 


A flag activating the NO beta band system. 

treat_band_no_delta 

A flag activating the NO delta band system. 

treat _band_no_epsilon 

A flag activating the NO epsilon band system. 

additional molecular band systems: This paragraph lists molecular band 

systems available in addition to those listed in the paragraph above. The 
band systems listed here are generally weak emitters and absorbers, and are 
therefore not engaged as a default. Therefore, for these band systems to be 
engaged, the following flags (0 = off, 1 = SRB, 2 = LBL) must be present 
in the hara_namelist_data hie. The LBL treatment of these bands is not 
recommended. 

treat _band_c2_br 

A hag activating the C2 Ballik-Ramsay band system. 

treat_band_c2_da 

A hag activating the C2 Deslandres-d’Azambuja band system. 

treat_band_c2_fh 

A hag activating the C2 Fox-Herzberg band system. 

treat _band_c2_mulliken 

A hag activating the C2 Mulliken band system. 

treat _band_c2_phil ip 

A hag activating the C2 Philips band system. 

treat _band_co3p 

A hag activating the CO 3+ band system. 

treat _band_co_angstrora 

A hag activating the CO angstrom band system. 

treat _band_co_asundi 

A hag activating the CO Asundi band system. 

treat _band_co_triplet 

A hag activating the CO triplet band system. 
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treat_band_co2 

A flag activating the CO 2 band system. A value of two activates an 
approximate nonequilibrium model for UV emission, while a value of 
one assumes Boltzmann emission. The LBL treatment of this band is 
not available. 

treat _band_n2_cy 

A flag activating the N 2 Carrol- Yoshino band system. 

treat _band_n2_wj 

A flag activating the N 2 Worley-Jenkins band system. 

treat _band_n2_worley 

A flag activating the N 2 Worley band system. 

treat _band_no_gamma 

A flag activating the NO gamma band system. 

treat _band_no_betap 

A flag activating the NO beta-prime band system. 

treat _band_no_gammap 

A flag activating the NO gamma-prime band system. 

treat _band_o2_sr 

A flag activating the O 2 Schumann-Runge band system. 

treat_ [?] _photo_dis 

A binary flag activating the molecular photo-dissociation mechanism [72] 
for [?] specie, where [?] can be 02 or N2. This mechanism is not 
technically a molecular band system. 

treat. [?] _photo_ion 

A binary flag activating the molecular photo-ionization mechanism [72] 
for [?] specie, where [?] can be 02 or N2. This mechanism is not 
technically a molecular band system. 

treat_no_photo 

A binary flag activating the molecular photo-ionization mechanism [72] 
for NO. 
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atomic line models: There are various models available for atomic line radi- 

ation, one of which must be chosen for each specie that engages atomic line ra- 
diation (as specified using treat. [?] .lines). This choice of atomic line model 
is made using the following flags. The listed defaults are applied if the indi- 
vidual flag is not present in hara_namelist.dat a, or if hara_namelist.dat a 
is not present in the working directory. All model types in this category must 
be surrounded by a quotation marks. 

c.atomic.linejnodel, h.atomic.line unodel 

A character identifier for selecting the atomic line model for atomic car- 
bon or hydrogen. Presently, the only available option is the model com- 
piled in Ref. [71], which is referred to here as the Complete Line Model 
(CLM). Default : ‘elm’ 

n_atomic_line_model, o.atomic.lineunodel 

A character identifier for selecting the atomic line model for atomic ni- 
trogen or oxygen. The available models are compiled and compared in 
Ref. [69], which is referred to here as the Complete Line Model (CLM). 
Default : ‘elm’ Available models are: 

‘all multiplets’ 

This model treats all lines as grouped multiplets. This significantly 
reduces the number of lines treated as well as the computational 
expense. However, this grouped multiplet approximation will lead 
to errors for non-optically-thin conditions. 

‘ elm’ 

This model, which stands for Complete Line Model, applies the 
individual treatment of strong atomic lines while applying multiplet 
averages for weak lines. This is the recommended model. 

electronic state population models: These flags specify the model ap- 

plied for predicting the electronic state populations of atoms and molecules. 
The listed defaults are applied if the individual flag is not present in 
hara.namelist.data, or if hara.namelist.data is not present in the working 
directory. All model types in this category must be surrounded by a quotation 
marks, e.g. ‘ ’. 

atomic electronic states 

The electronic state populations for atoms are required for computing atomic 
line and photoionization emission and absorption. The compilation and com- 
parison of the available models are presented in Ref. [70]. 
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c_electronic_state, h_electronic_state 


A character identifier for selecting the electronic state model for atomic 
carbon and hydrogen. Available models are (default : ‘boltzmann’): 

‘ boltzmann’ 

Applies Boltzmann population of electronic states. 

‘ Gally_lst_order_LTNE’ 

Applies the Gaily first-order local thermodynamic noneqnilibrium 
method [73], which approximately accounts for the non-Boltzmann 
population of atomic states. 

n_electronic_state, o_electronic_state 

A character identifier for selecting the electronic state model for atomic 
nitrogen and oxygen. Available models are (default : ‘CR’): 

‘ boltzmann’ 

Same as for c_electronic_state 

‘ Gally_lst_order_LTNE’ 

Same as for c_electronic_state 

‘ CR’ 

Applies the detailed collisional radiative (CR) model developed in 
Ref. [70], 

‘ AARC ’ 

Applies the approximate atomic collisional radiative (AARC) model 
developed in Ref. [70]. This model is essentially a curve-fit based 
approximation of the CR model, which allows for improved compu- 
tational efficiency with a slight loss in accuracy. 

molecular electronic states 

The electronic state populations for molecules are required for computing 
molecular band emission and absorption. The compilation and comparison 
of the available models are presented in Refs. [70,74], 

molecular_electronic_state 

A character identifier for selecting molecular electronic state for all molec- 
ular band systems. Available models are (default : ‘CR’): 

‘ boltzmann’ 

Applies Boltzmann population of electronic states. 
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f CR’ 

Applies a detailed collisional radiative model considering both heavy- 
particle and electron impact transitions. Some molecular states 
are still assumed Boltzmann with this model because no data is 
presently available for the CR model. 

other flags: 

use.triangles 

A logical flag specifying whether optically-thin atomic lines are modeled 
as triangles to reduce computational time. This option has shown to 
result in a negligible loss of accuracy while greatly reducing the compu- 
tational time, [69] and is therefore recommended. Default : .true. Note: 
This flag is automatically set to .true, when n_ or o_atomic_line_model= 

‘ elm’ — see atomic line models earlier in this section. 

use_edge_shift 

A logical flag to engage the photoionization edge shift [69] for atomic 
bound-free radiation. (on=l/off=0). Default : .true. 
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Appendix C 


Troubleshooting 


The goal of the Fun 3D developers is to produce as robust a solver as 
possible. However, there are times when the code fails to produce a converged 
solution. For example, taking the square root of a negative quantity (due to a 
negative density or pressure) results in a NaN. We hope that these suggestions 
are helpful. If none of the suggestions listed here remedy your problem, please 
contact Fun3D-Support@lists . nasa . gov. 


C.l What if the solver has trouble starting or reports 
NaNs? 

Check that the freestream, reference, and boundary conditions are specified 
correctly. Visualize the solution, especially near the location of the maximum 
residual. If the problem is widespread, run the simulation again and visualize 
the solution a few iterations before the problem happens. Look for extremely 
large Mach numbers, low pressures, low densities, or reversed flow at bound- 
aries. 

Examining the residual history may help to isolate the problem to the 
mean flow or turbulence model. Lowering the CFL numbers of the mean- 
flow and turbulence equations can aid linear and nonlinear convergence, see 
section B.4.14. If the linear system is diverging (the linear system can be exam- 
ined with the — monitor_l inear command line option), increase the number 
of sweeps or utilize the Krylov projection method linear .projections true., 
see section B.4.15. 

Try flow field initialization in the problematic region of the domain (e.g., 
engine plenum), see section B.4.19. Start with some f irst_order_iterations 
(section B.4.9) or try continuation from less challenging freestream condition 
(e.g., lower angle of attack, subsonic Mach number). 


C.2 What if the forces and moments aren’t steady or 
residuals don’t converge to steady-state? 

Try lowering the CFL numbers of the mean flow and turbulence model, see 
section B.4.14. Examining the residual history may help to isolate the problem 
to the mean flow or turbulence model. The problem may be unsteady; try 
restarting the solution with a time-accurate simulation. 
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C.3 What if the solver dies unexpectedly? 

You may need to set your shell limits to unlimited, 

$ ulimit unlimited # for bash 
$ unlimit # for c shell 

If your operating system reports a Signal 9 or 11 and you have already tried 
removing shell restrictions, you have likely hit the memory limit of your ma- 
chine. Try reducing the number of mesh points, running on more nodes, or 
installing more memory on your machine. 

C.4 What if a segmentation fault occurs after “Calling 
ParMetis”? 

Make sure that the the width (32 or 64 bits) of integers in Fun 3D and 
ParMETIS are consistent. More recent implementations of MPI (e.g., Open- 
MPI) internally manage the handles (i.e. , communicators) differently from 
previous versions of MPI. However, ParMETIS 3.* uses an older paradigm, 
which has been updated in ParMETIS 4.*. Upgrade to ParMETIS 4.*. 

C.5 What if the solver dies with an error like “input 
statement requires too much data” after echoing 
the wrong number of elements or nodes? 

The endianness (section 4.1) of the grid hies (section 4) may be different than 
Fun 3D expects. 

C.6 What if the solver dies with an error like “input 
statement requires too much data” after echoing 
the number of tetrahedra and nodes for a VGRID 
mesh? 

Single-segmented VGRID grids over 20 million nodes exceed the allowable 
record length. Use postgrid to save grid as a multi-segmented format (option 
05 in batch mode). 

C.7 What if the solver reports that the Euler numbers 
differ? 

The Euler number is a global indicator of consistent node, element, and face 
connectivity. There is some limited evidence that suggests there may be times 
when it reports a problem that may not be an issue for the solver, but the 
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failure of the Euler number check indicates a problem with the grid in a ma- 
jority of cases. Instructions to determine if the Euler number will impact your 
solution follow this description of the Euler number. 

C.7.1 Euler Number Description 

A valid grid is composed of four elemental volume types (tetrahedra, pyra- 
mids, prisms, and hexahedra) face-connected either to each other or one of 
two boundary face types (triangles or quadrilaterals). Each boundary edge 
connects to precisely two boundary faces. Two neighboring boundary faces 
share exactly one boundary edge. For each boundary face connecting to a 
boundary node, every other boundary face connecting to the same boundary 
node can be found by a path through a connected-edge/connected-face traverse 
starting from that boundary face. 

The above restrictions are meant to exclude certain topologies such as two 
spherical boundaries coming together at a point or two rectangular boundaries 
connecting along an edge. These restrictions are not checked explicitly but will 
cause the Euler number check described below to fail. 

The Euler Number computed from boundary data (EN b ) is 

EN b = N b -E b + F h (Cl) 

where 

N b = boundary nodes (counted) (C2) 

E b = boundary edges (inferred fromAA* and N quad ) (C3) 

F b = boundary faces (inferred from N tri and N quad ) (C4) 

The Euler number is a characteristic number for the topology of the boundary 
or boundaries. N tri and N quad are the number of triangular and boundary 
faces, respectively. 

The Euler Number computed from volume data ( EN V ) is 


EN V = 2 (N-E + F-C) (C5) 

where 

N = volume nodes (counted) (C6) 

E = volume edges (counted) (C7) 

F = volume faces (inferred from C and F b ) (C8) 

C = volume cells (counted) (C9) 

The formula that is checked is 

EN V - EN b = 0 (CIO) 
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Barth [75] derived this formula for tetrahedra and noted the formula does 
not hold in certain cases, such as two simplices that share only one common 
edge or two simplices that share only one common node. Barth notes that the 
above formulas are specific forms of the general Dehn-Sommerville formula, 
reported in Wikipedia to hold for simplicial polytopes and simple polytopes. 
The pyramid is not a simple polytope. It can be proved by induction [76] that 
the formula holds for every valid grid as defined above. 

Try this checklist to diagnose the problem: 

1. Check the EN b with your expectations for this case: 

2 for a spherical topology, simple 3D wing with symmetry, . . . 

0 for a torus, donut, . . . 

-2 for a double torus, . . . 

-4 for a triple torus, pretzel, . . . 

4 for a sphere within a sphere, . . . 

6 for two spheres within a sphere, . . . 

2. Ensure the number of boundary nodes N b and faces F b reported match 
expected values. 

3. Ensure the number of nodes N and cells C reported match expected 
values. 

4. The difference between EN b and EN V points to inconsistencies in edge 
counts, i.e., 5(E) = 2 (EN b — EN V ) ^ 0. The inequality EN b > EN V 
implies you have more edges than expected. When this occurs, the re- 
ported face counts will differ from an actual count. An error of this type 
would arise when there are adjacent faces that are inconsistent, such as 
a quadrilateral face shared between two elements that is cut into two 
triangular faces by different edges. 

C.7.2 Determining the Impact of an Euler Number Mismatch 

A freestream residual problem localization technique is described. However, 
the best practice is to not proceed without repairing the grid to ensure EN b = 
EN V . The ignore_euler_number namelist variable does just what the name 
implies, and allows the solver to proceed. The --test_freestream option can 
be used as a secondary check on the mesh. On a valid mesh, the solver should 
preserve the freestream for an arbitrary number of iterations. You should run 
20-50 iterations, which may require a lowering of the stoppingvtolerance 
to le-20 so the solver does not automatically stop. All residuals should 
hover around machine zero, and not slowly increase (there will be iteration- 
to-iteration variation in the exact number, however). 
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If freestream is maintained by this test, you could proceed with your in- 
tended computation using only ignore_euler_number, but this is not recom- 
mended. If freestream is not maintained, this test confirms that there is a 
problem with the mesh and the location of the max residual may give a clue 
as to where in the mesh to start looking for the problem. 
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